? Before · a framework to interpret
“I want to try. Am I allowed to?”
- Rules scattered across several documents.
- Uncertainty about which data and tools can be used.
- No clear person to ask.
Workshop · company, department or team
Your teams want to use AI.
Give them a framework to move forward.
Clear rules, useful resources and the right support. Build your first AI governance framework together, then test it in a living mindBrain model.
From €6,000 · 4 half-days of work
From a concrete case to an actionable answer
Our starting situation
CUSTOMER SERVICE · FICTIONAL EXAMPLEA BUSINESS QUESTIONExample framework
Can I draft a customer reply with this AI?
Yes, under conditions.
In the approved environment, with the intended data. The result remains a draft to review.
Justified rule · linked guide · identified owner
Local illustration, with no connection to mindBrain.
01
A framework people can use every day
Know what to do, how to do it and who to ask for help.
02
Answers put to the test
Your scenarios compared with expected outcomes, not a vague promise.
03
4 structured half-days
A first scope, deliverables at every step and an agreed schedule.
04
Your business, not code
You describe and decide. We facilitate and formalize the model.
The outcome we seek
Move from “Is this allowed?”
to “Here is how to do it.”
The same governance should help people who use AI, oversee the work and maintain the rules.
✓ After · a framework to use
“I know how to move forward.”
- An answer adapted to the situation, with its limits.
- The rule, the useful resource and the right person.
- A clear path for proposing a new use.
? Before · a framework to interpret
“Everything comes back to me, even simple cases.”
- Repeated decisions, often handled case by case.
- Real uses that are difficult to make visible.
- An unclear approval responsibility.
✓ After · a framework to use
“The framework is shared. Exceptions are visible.”
- Common situations described and tested.
- Decisions, owners and open points identified.
- A basis for supporting the team and tracking requests.
? Before · a framework to interpret
“The policy exists. Its application remains unclear.”
- Interpretations that vary from team to team.
- Rules disconnected from processes and tools.
- Changes whose impact must be reconstructed.
✓ After · a framework to use
“I can explain and review the framework.”
- Rules linked to their sources and scope.
- Scenarios for checking expected answers.
- A model to maintain, with identified approvals.
Illustrative before / after: the target state concerns the scope being worked on. These are not measured client results.
01 · Build together
You describe the work.
The framework takes shape.
Cards, sticky notes and real situations. Five acts in business language reveal use cases, rules and resources.
Our starting point: a customer service employee wants to draft a reply to a complaint with AI, using the CRM and an ERP order. What can they use, do and have approved?
Act 01 / 05 · business language
What are we talking about?
We describe a real situation before writing a rule. The cards reveal the people, documents, data and systems involved.
- Who is trying to accomplish what?
- Which information and tools are being used?
- Who can help or make the decision?
What we identifyA shared vocabulary and the scope of the case to govern.
Act 02 / 05 · business language
What happens?
We follow what people actually do. Reading, sharing, drafting a reply and sending it are different actions and may require different controls.
- Who reads, shares or transforms data?
- What does AI prepare, and what does the person decide?
- At what point does an action commit the company?
What we identifyInteractions, responsibilities and handovers between systems.
Act 03 / 05 · business language
How do we describe it?
We qualify information, environments and decisions. A proposed use is not an approved use. Unclassified data is not public data.
- Is the data public, internal or confidential?
- Has the environment been assessed for this specific use?
- Is the rule proposed, approved or superseded?
What we identifyProperties, states and life cycles that make rules precise.
Act 04 / 05 · business language
When does it change?
We turn intuitions into explicit conditions. Event cards reveal exceptions: sensitive data, missing approval or a changed contract.
- When should the case be allowed, refused or reviewed?
- Who approves, and what happens without approval?
- Which alternative lets people work within the framework?
What we identifyIF… THEN rules, their owners and the unknowns to resolve.
Act 05 / 05 · business language
How do we find it again?
We formulate the questions employees, managers and agents will need to answer. The framework becomes searchable from their situation.
- Can I use this data for this task?
- Who can approve, and which resource can help me?
- Which uses are affected when a rule changes?
What we identifyBusiness questions, the information they require and search paths.
The business decides the framework.
Employees bring the situations. Competent people approve what falls within their mandate. Unknowns remain visible: they never become default permissions.
Cross-functional from the first case
Connect rules to the work.
Do more than file them.
We select the domains needed for the chosen process. There is no need to model the whole company to begin.
Texts, connected to their application.
We distinguish the source, its interpretation, its applicability and the operational rule adopted. Uncertain points remain visible.
A business question becomes accessible
“Which obligations have been identified for this use?”
Source text→Applicability approved→Rule→Use
Legal interpretations and approvals remain the responsibility of competent people. An internal rule cannot override a legal obligation.
Your procedures, in context.
Security, publishing, purchasing and retention rules are connected to concrete tasks and decisions. One procedure can govern several teams.
A business question becomes accessible
“What should I check before sharing this document?”
Procedure→Data→Action→Control
The source, version, owner and review date are kept. Modeling a control does not mean it is already enforced in a tool.
A framework that helps people move forward.
We connect roles and responsibilities to useful resources: guides, approved examples, learning paths and people who can help.
A business question becomes accessible
“Which method can I follow, and who can help me?”
Employee→Use→Resource→Lead
A learning need becomes a support path. Approval depends on the chosen mandate, not only on a job title.
The specific use, not just the tool.
We describe the purpose, environment, configuration, data categories and flows. The agent’s level of autonomy is handled explicitly.
A business question becomes accessible
« Is this environment appropriate for this task and data? »
Task→Data→Environnement→Autorisation
Access rights, information freshness and unevaluated points are part of the model. Production connections are defined separately.
Governance meets real work.
We connect rules to the objects that move through the process: a customer file, an order, an invoice, a role or training. Existing applications remain in place.
A business question becomes accessible
« What can the agent do with this file, and under which mandate? »
CRM file→Commande ERP→HR role→Action IA
We model the objects useful to the chosen case, not the whole application estate. A relation in the model is not an API connection already deployed.
02 · Model, test, validate
The sticky notes do not stay
on the wall.
They become a living model in mindBrain: connected ontologies, explicit rules and business questions that can be tested.
INTERACTIVE EXPLORATION
The journey below illustrates the method. Synthetic data and a local demonstration engine.
From workshop to model · fictional example
What you named becomes connected.
Objects, properties and links help retrieve the rules relevant to a situation. Click an element to explore its place in the model.
Business use
Draft a customer reply
A purpose, data, an environment and an action. This use connects the domains without conflating them.
Associated question: “Can I draft this reply in this situation?”
01 · Describe
The semantic model: what exists and how it is qualified.
02 · Connect
The graph and links between domains: rules, relations and conditions.
03 · Expose
Projections: useful views for people and agents, without inventing information.
Local simulation · fictional internal rules
Change the context. Observe the answer.
The same tool does not give the same answer in every situation. Change the settings or choose a starting case.
Allowed with conditions
Yes, to draft a reply.
In this example, internal data can be used in the approved environment. The outcome remains a draft to review, with no automatic sending.
Fictional rules F-R03 · F-R04 · Example policy v1
Your support pointFictional guide “Draft a customer reply” and the team’s AI lead.
Educational illustration calculated in your browser. No connection to mindBrain, no AI call, no real-data processing and no external action.
See the fictional rules used by this simulator
F-R01Internal or confidential data is not allowed in an unapproved personal account.F-R02An unknown data category or assessment requires review. A personal tool still needs assessment, even for public data.F-R03The environment must be approved for the example scope.F-R04Drafting a reply requires review before any external use.F-R05An external send requires approval by the authorized person.
These rules only illustrate the method. They are neither a policy recommended for every company nor a legal decision.
Business questions · illustrative answers
A useful answer also says how to move forward.
The outcome, its justification, its limits and accessible support. Choose a question to see a possible answer.
Employee perspective
Yes, within the described framework.
For this fictional file classified as internal, prepare only a draft in the approved environment. The external reply must follow the required approval.
What does this answer rely on?
Internal data→F-R03 / F-R04→Drafting guide
Missing data or assessment: the answer would become “requires review”.
Prewritten examples based on the fictional model. In the workshop, questions and expected answers are defined with the scope owners.
Verification · expected / actual answers
Does the framework work for the chosen cases?
A positive answer is not always the right outcome. A model must also refuse, request approval or acknowledge missing information.
Teaching suite ready. 6 fictional cases to compare with the simulator engine.
| Fictional situation | Expected decision | Actual result |
|---|---|---|
| Draft / approved framework | Allowed with conditions | To test |
| Confidential data / personal account | Not allowed | To test |
| Unknown data category | Requires review | To test |
| Sending / approval missing | Approval required | To test |
| Sending / approval present | Allowed in this example | To test |
| Environment not assessed | Requires review | To test |
In the workshop
Compare answers, justifications and support guidance with the approved expectations.
Before activation
Document gaps, coverage, sources and missing approvals.
After deployment
Track response times, requests for help and uncovered cases, using the data available.
The score compares only the decisions for these six synthetic cases. It measures neither your compliance, production effectiveness nor any real time saving.
A living model · maintenance and validation
When a rule changes, the work continues.
Living does not mean all-knowing. New information must be added, its effects identified and changes approved before publication.
Proposed change · review required
The assessment of the new environment is missing. Dependent uses must be reviewed.
1
The change is identified
It is provided by an owner or received from an integrated source.
2
Related uses must be reviewed
Draft preparation, sending approvals and related resources.
3
Review then human approval
The missing assessment must be provided and reviewed before a decision is made.
4
Publication after approval
The revised version and its resources become available within the chosen scope.
The button simulates adding missing information and approval. It does not approve any real tool. A policy change is separate from executing controls in applications.
Modeling ≠ enforcing a technical control. Application permissions, connections and blocking mechanisms require a defined and tested deployment.
A living model has owners. Its sources, versions, approvals and access rights must be maintained. It cannot know about changes that are not added to it.
One journey, not four isolated meetings
4 half-days.
From the first case to testing.
A format spread across collective work, formalization and validation. Each step builds on what came before.
Half-day 01
Start from the work, not the policy.
We choose a first cross-functional process and the situations that need a clear answer.
You bring
Your examples, questions and existing documents.
We work on
Facilitating the story, first Names and Verbs, and identifying states and areas of doubt.
You leave with
A shared scope, a map of uses and the first business questions.
Half-day 02
Build workable conditions.
The five acts are completed with edge cases, responsibilities and resources.
You bring
Business decisions and the people competent to provide the required approvals.
We work on
Event card exercises, condition drafting, case classification and support paths.
You leave with
Proposed or approved rules, their owners and points still requiring review.
Half-day 03
Connect what has been produced.
Captured elements become a semantic model, relationships and business-oriented views.
You bring
Your review of the vocabulary and links. You do not code the model.
We work on
Ontology formalization, cross-domain links and preparation of synthetic test instances.
You leave with
A first model of the chosen scope, with questions and rules to test.
Half-day 04
Check, correct and hand over.
We compare the model with expected answers, including cases where it should refuse to conclude.
You bring
Scope owners to check results and remaining open decisions.
We work on
Scenario testing, gap analysis, agreed corrections and maintenance definition.
You leave with
The revised model, test results, support kit and list of next steps.
Understand & share
The map of uses and responsibilities
A shared vocabulary, decisions made and points that remain open.
Ask & verify
The model and its test scenarios
Rules, questions and links in mindBrain for the agreed scope.
Support & maintain
The support and handover kit
Useful resources, the support path and update responsibilities.
The five acts describe the capture method; the four half-days describe the service. The proposed schedule and participant involvement are adjusted during scoping.
Explore the method
“How I would approach it
with my team.”
Three mini-tutorials to move from a governance intention to a first practical exercise.
01 · START FROM USESMINI-TUTORIAL
I would start with three situations, not a policy.
Have people describe the work and identify the first areas of doubt.
02 · MAKE THE FRAMEWORK USEFULMINI-TUTORIAL
I would connect every rule to a way forward.
Connect a condition to a resource, an owner and an answer.
03 · TEST BEFORE EXPANDINGMINI-TUTORIAL
I would also test cases where the answer must be no.
Put the model against exceptions and missing information.
Living AI Governance workshop
Stop making your teams
guess the framework.
Build governance they can understand, question and use to move forward.
- A first cross-functional process, chosen with you.
- Participatory workshops and formalization in mindBrain.
- Rules and questions tested against your scenarios.
- Resources, responsibilities and clearly defined next steps.
Your first operational framework
Workshops + mindBrain model + tests
From
6 000 €
for 4 half-days of work
One teamOne departmentOne company-wide scope
We define the scope, participants and scenarios to test before confirming the proposal.
You bring your situations and decisions. We guide the workshop and build the model.
The starting price covers an agreed first scope. Complexity, exact deliverables, timing and tax conditions are specified in the proposal.
Hosting, possible licences, application integrations and maintenance: conditions to be specified in the proposal. The workshop is neither a certification, a full audit nor a compliance guarantee.
Before we begin
The questions
that matter.
An explicit collaboration framework from the start.
Do we need an AI policy already?
No. We can start from business situations and available documents. If a policy exists, it becomes a source to connect to uses, rules and questions. It is not replaced by default.
Who should take part?
A scope owner, employees who know the work and the functions needed for decisions: business, IT, security, data protection or legal, depending on the case. Experts contribute on matters within their mandate.
Do we need to code or understand ontologies?
No. You describe your work in natural language, examine situations and approve decisions. We handle formalization. Your business involvement and decisions remain essential.
Is this a complete compliance exercise?
No. The workshop builds and tests a first framework on an agreed scope. Legal interpretations must be approved by competent people. Uncovered topics and missing approvals are identified.
Is the model connected to our ERP, CRM and HR systems?
Useful objects can be represented and connected during modeling. A production integration is separate work: access, synchronization, security, controls and operations must be defined. They are not activated by this demonstration page.
How do we check the effectiveness of the work?
Before testing, we define the decisions and expected answers for the scope scenarios. We then compare results, justifications and guidance to the right support. Gaps and limits are documented. Real-world effectiveness is assessed after activation using agreed indicators and observed data.
What happens after the four half-days?
The handover specifies who maintains the model, which sources must be reviewed and which actions remain. Expansion to other scopes, integrations and ongoing support are defined separately. Four half-days do not represent a guaranteed calendar deadline.
From 6 000 €4 half-days