Operational data and AI governance: from pilot to monitoring
A practical workflow for approving AI solutions, evaluating RAG, resolving data incidents, controlling changes and agreeing on data sharing.
Practical guide · Reviewed 4 November 2026. The workflow and examples are editorial suggestions, not client cases or universal legal requirements.
1. A lifecycle with decisions and evidence
Start with one solution rather than a programme covering the whole organisation. Record who owns the outcome, which data it uses, who is affected and what actions it can take. A drafting assistant needs different controls from a tool authorised to execute payments.
| Stage | Decision maker | Working evidence | Condition to proceed |
|---|---|---|---|
| Propose | Business owner | Objective, intended use, affected people and alternative without AI | Benefit and scope defined |
| Assess | Business with data, security and privacy specialists as needed | Inventory, risks, permitted data and supplier assessment | Critical risks treated or decision to stop |
| Approve a pilot | Person authorised to accept residual risk | Tests, limits, oversight and rollback plan | Critical tests passed and approval recorded |
| Operate | Service owner | Metrics, alerts, incidents and access reviews | Monitoring and escalation available |
| Change or retire | Service and business owners | Impact, reassessment or closure, revoked access and retention | Consumers informed and retention duties checked |
One person may hold several roles in a small organisation, but distinguish who performs the work from who accepts the risk. At each stage record the decision, date, owner, version and unresolved issues. Missing critical evidence should pause progression: a favourable average score cannot compensate for a serious failure.
Prepare with the existing guides on AI inventories, supplier assessment and human oversight.
2. Evaluate generative AI and RAG before and after changes
A convincing answer is not evidence of correctness. Prepare an evaluation set separate from the examples used to tune the system. Record the question, authorised context, source and version, expected answer or acceptance criterion, and error severity.
Illustrative example: an internal expenses-policy assistant could start with 30 common questions, 10 ambiguous questions, 10 questions not answered by its documents and 10 attempts to obtain unauthorised information. This is a pilot design, not a statistically representative sample or mandatory minimum.
- Retrieval: does it find the current source and enforce the user’s permissions?
- Answer: does the claim match its source, cite supporting material and express uncertainty?
- Abstention: does it request clarification or escalate when information is insufficient?
- Security: does it resist malicious instructions embedded in documents and avoid disclosing restricted data?
- Operation: does it meet agreed latency and cost, with human review where planned?
Measure categories separately. For example, “correct answers with a valid source / answerable questions evaluated” should not mix in questions that should have been refused. Break results down by language, user group and use case where risk warrants it. High performance on easy questions does not demonstrate fairness or security.
Define criteria before testing. An internal rule might block a pilot after any unauthorised disclosure in the critical cases tested. Passing does not guarantee the absence of failures: add cases from actual incidents, minimise personal data and repeat tests after model, source or permission changes. Keep configuration, results and the approval decision.
Continue with answer validation and data quality for RAG.
3. From a data alert to a resolved incident
Select a critical dataset, its owner and the people consuming its outputs. Define freshness, volume, schema and content checks. For each rule record the measured population, formula, threshold, frequency and action. An alert without a recipient or agreed response adds noise.
Illustrative example: a daily customer master must arrive before 08:00. If it does not, notify the technical team and display the last valid load date on the report. If duplicate identifiers appear, isolate the affected batch for review; do not automatically delete records without an approved resolution rule.
- Detect and record: dataset, run, failed rule, time and affected records without unnecessarily copying sensitive data.
- Assess impact: affected reports, processes and AI systems; prioritise consequences.
- Contain: hold a batch, warn consumers or use an approved fallback.
- Fix the cause: assign an owner and determine whether capture, transformation or definition failed.
- Verify and close: rerun checks, confirm recovery with consumers and record how to prevent recurrence.
Track detection and recovery time, recurring issues and the share of critical rules with an owner. Segment by severity so averages do not hide serious problems. See quality formulas and dashboards by audience.
4. Control data, model and supplier changes
Treat a new model version, prompt, document source, permission set, schema or supplier as a change even when the service’s commercial name stays the same. Record the reason, affected components, consumers, tests, authorisation and rollback plan.
- Data: check compatibility, definitions, units, retention and consumers using lineage and data contracts.
- AI: rerun the evaluation set, compare regressions by category and confirm limits and oversight.
- Supplier: review data processing, subcontractors, terms, export capability and exit arrangements.
- Retirement: notify users, revoke credentials and access, close integrations and apply the relevant retention or deletion rules. Do not delete evidence subject to retention duties.
Illustrative example: changing “amount” from euros to cents can preserve a numeric field type while breaking a finance report. A schema test alone will not detect the meaning change: add a semantic check and consumer validation. Data contracts help make that agreement explicit.
5. Share data and agree on permitted use
Before sending a file or opening an API, identify the sender, recipient, purpose, affected people, jurisdictions and basis permitting that use. Technical access does not automatically authorise model training or reuse for another purpose.
Document fields and classification, permitted and prohibited uses, recipients, access controls, retention, return or deletion, incidents and change handling. Check licences, third-party rights, confidentiality and transfer restrictions. Contract terms must match the controls the system can actually enforce.
In the EU, the Data Act addresses connected-product data and switching data-processing services, among other subjects. The Commission dates general application to 12 September 2025, with specific provisions to examine. It does not replace GDPR. For other countries, assess local rules and the particular transfers using the regulatory radar.
A manageable first delivery
Choose one case and prepare five records: a use-case description, decision responsibilities, a test set, an incident log and a change log. Agree who maintains them and when they are reviewed. The first goal is to explain a decision and show what was checked, rather than accumulate documents.