Companies often respond to the arrival of AI with a brief charter of a few pages: do not share confidential data, verify the results, and comply with the law. These rules are necessary, but they do not make it possible to know which systems are used, who decides, which versions are in production, or whether the risks are actually monitored.
Conversely, an overly cumbersome program pushes teams to bypass the process. Governance must therefore be proportionate: light for a writing assistant without sensitive data, demanding for an agent connected to the information system or a decision concerning people.
Governance must be adapted to the context of the organization and aligned with its legal, contractual, sectoral, and security obligations.
Governance is not a committee
A committee can arbitrate, but it does not by itself constitute a management system. Operational governance constantly answers six questions:
- what systems exist; 2. who is responsible for them; 3. what uses are allowed; 4. what evidence supports the decision; 5. what changes have taken place; 6. when it is necessary to reassess or stop.
It integrates into the processes already in place: procurement, security, data protection, architecture, development, internal control, human resources, and incident management.
Define a clear scope
The term 'AI system' must be translated into the company's language. The register may include:
- internally developed models;
- external APIs;
- AI functions of a SaaS;
- documentary RAGs;
- agents and automations;
- content generation tools;
- development assistants;
- embedded models;
- experiments using real data.
A simple rule engine does not necessarily need the same circuit. The goal is not to artificially inflate the record, but to cover systems whose behavior, data, or autonomy create a particular risk.
Write a policy that helps to decide
A useful policy is based on a few understandable principles, supplemented by procedures. It specifies:
- freely allowed uses;
- approved tools;
- forbidden or conditional data;
- uses requiring review;
- decisions that remain human;
- transparency rules;
- ownership of content and code;
- security requirements;
- reporting of errors and incidents;
- sanctions or measures in case of voluntary circumvention.
Concrete examples are more useful than a general rule. 'Do not send personal data' is often impractical. It is better to distinguish public, internal, confidential, secret, common personal data, and sensitive data, then associate each level with the authorized environments.
The minimal viable register
The register starts with a limited number of mandatory fields:
- identifier and name;
- purpose description;
- business owner;
- technical owner;
- lifecycle status;
- users and affected persons;
- supplier, model, and version;
- data used;
- connected systems;
- level of autonomy;
- main risks;
- available assessments;
- decision and conditions;
- date of next review.
He must accept uncertainty. An "unknown version" value is preferable to an empty field, because it triggers an action. The quality of the register is measured by its ability to reveal the unknowns, not by its perfect appearance.
Data model of an AI registry linking use cases, responsible parties, versions, data, evaluations, decisions, and incidents.
Classify uses by level of control
A simple internal classification facilitates proportionality.
Level 1: support without sensitive data
Writing, translation, or ideation from public content, without significant decision-making. Controls: approved tool, training, human review, and ownership rules.
Level 2: internal data or business recommendation
Summary of internal documents, assistance with analysis or augmented research. Additional controls: contract, access, retention, evaluation, sources, and error tracking.
Level 3: significant action or impact
Connected agent, process automation, recommendation influencing a person, or use of sensitive data. Enhanced controls: impact analysis, security, approval, supervision, logs, recourse, adversarial testing, and incident plan.
Level 4: prohibited, regulated, or critical use
The project is blocked until qualification by the competent roles and implementation of the specific requirements.
This internal scale does not replace legal classifications. It is used to guide the process.
Set up decision gates
The life cycle includes at least four stages.
Idea towards experimentation
Check purpose, owner, tool, authorized data, and isolated environment. A POC should not automatically receive production access.
Experimentation towards pilot
Require an evaluation set, results, an error analysis, data mapping, costs, and an initial security/GDPR review.
Pilot to production
Validate thresholds, monitoring, responsibility, support, contract, recovery, user documentation, human supervision, and withdrawal plan.
Production towards major change
A new model version, a new tool, another population, or an additional writing right triggers a targeted reevaluation.
Each gate produces a dated decision: approved, approved with conditions, refused, or additional information.
Distribute the responsibilities
The business owner is responsible for the purpose, the use, and the expected results. The technical owner is responsible for the architecture, versions, integrations, and operations. The DPO, security, legal, and internal control intervene according to the risk.
The AI committee should not review every prompt. It arbitrates complex cases, defines levels, monitors incidents, and decides on exceptions. Standard cases follow an automated or delegated process.
A typical RACI specifies who:
- proposes;
- evaluates;
- approves;
- deploys;
- monitors;
- informs people;
- manages incidents;
- decides on withdrawal.
Organize the evidence
Each entry in the register points to the documents, not to a simple 'compliant' box. The evidence includes:
- supplier sheet;
- contract and subcontractors;
- architecture and flows;
- AI Act/GDPR/security analyses;
- evaluation set;
- results report;
- supervision model;
- instructions and workflows;
- decisions;
- incidents;
- version history.
The organization can draw inspiration from ISO/IEC 42001 to structure leadership, risks, lifecycle, measurement, and continuous improvement, without claiming to be certified if it is not.
Governing the changes
An AI system sometimes evolves without code deployment: the provider replaces a model, modifies a filter, increases a context window, or adds memory. The contract and supervision must allow for detecting these changes.
Define the events that trigger a review:
- new version;
- new data;
- new population;
- new action;
- quality decrease;
- incident;
- regulatory change;
- end of support;
- change of subcontractor.
A journal links the event to the decision and the tests carried out.
Measuring governance
Useful indicators are not the number of meetings or pages produced. Instead, track:
- percentage of systems with an owner;
- proportion of known versions;
- coverage of assessments;
- request processing times;
- number of expired exceptions;
- incidents by level;
- systems without recent review;
- overdue remediation actions;
- detected uses outside the register;
- removal or rollback time.
These metrics reveal the actual ability to control the portfolio.
Handling exceptions without creating a backdoor
An exception contains a justification, a scope, an owner, compensatory measures, and an expiration date. It does not renew automatically.
For example, a limited test may use a non-standard provider with synthetic data, a separate environment, and verified deletion. The exception does not allow silent deployment to production.
Link governance and user experience
Governance is materialized in the product: transparency messages, sources, possibility to correct, consents if necessary, human oversight, history, and recourse. It is not just a back-office task.
User feedback feeds the register: recurring errors, misunderstandings, biases, abandonment, or workarounds. A system 'compliant on paper' but unusable creates its own risks.
Start small, but with a scalable model
A company can start in six weeks:
- appoint a person in charge;
- inventory the twenty most visible uses;
- adopt three or four levels of control;
- define decision gates;
- create a versioned register sheet;
- address the five priority risks;
- integrate purchasing and security;
- publish a simple policy;
- train the teams;
- measure and adjust.
Partitech can design the register, automate workflows, connect the evidence, and integrate controls into the development cycle. Good governance does not prevent experimentation: it allows you to know where you are experimenting, within what limits, and who is responsible for what follows.
Let's talk about your project
Design a proportionate AI governance system integrated into your processes with Partitech. Contact Partitech.