The operating model
Governing AI as an operating model, not a policy
AI governance fails in a predictable way. An organisation writes a good policy, convenes an ethics board, and then discovers it cannot answer the only three questions that matter: how many AI systems do we run, who is accountable for each one, and what evidence could we produce tomorrow morning.
The scarce resource is not controls. It is traceable, auditable workflow that moves an idea from intake to decision to production and back to retirement, with named humans accountable at every gate. This is that workflow, published in full.
Anchored to public frameworks: the EU AI Act, NIST AI RMF 1.0 and the Generative AI Profile (NIST AI 600-1), ISO/IEC 42001:2023 and the OECD AI Principles. Obligations are described by category rather than by date, because the Act’s phase-in schedule has been amended — verify current effective dates against the Official Journal before relying on them.
The wider landscape — binding law, treaties, technical standards, voluntary frameworks and regulator guidance across the EU, UK, US, Asia-Pacific, Canada and internationally — is set out in thestandards register.
Three pillars, one system
They are usually run as separate programmes, which is why they usually fail. Intake without accountability produces a backlog with no owner. Accountability without intake produces owners who do not know what they own. Both without responsible AI produce speed and no trust.
AI Intake
How does an AI idea enter the organisation safely and consistently?
Every proposed or discovered use case is captured, classified and routed, with traceability from idea to decision.
Without it you have a backlog nobody owns, and a shadow estate you cannot measure.
AI Accountability
Who is answerable when an AI system behaves well — or badly?
Named individuals own each system across its life, with evidence, approvals and an escalation path.
Without it you have owners who do not know what they own, and an hour lost to arguing who may press pause.
Responsible AI
Are these systems lawful, trustworthy and aligned with what we claim to value?
Risk is mapped and mitigated across validity, safety, fairness, transparency, privacy, oversight and the generative and agentic surfaces.
Without it you get speed and no trust, which is the most expensive combination available.
Does this reach you at all?
- — The EU AI Act applies extraterritorially. A provider or deployer established outside the EU is in scope where the system’s output is used in the EU — which catches a great many organisations that assume they are out of scope.
- — The provider and deployer split is the first question, not a detail. Badging someone else’s system as your own can make you the provider.
- — Free and open-source models carry partial exemptions, which do not extend to systems placed on the market as high-risk, nor to prohibited practices.
- — Sectoral regimes — model risk management in financial services, medical device regulation, employment law — sit on top and frequently bite sooner.
Design principles
- One front door
- Every AI idea reaches one intake. Nothing bypasses governance, including things bought rather than built.
- Risk-proportionate review
- Low-risk uses pass in days. High-risk uses get depth. Reviewing everything equally means reviewing everything badly.
- Named accountability
- Business, technical, model and data owners recorded at all times. Risk accepted by a committee is risk accepted by nobody.
- Evidence as a first-class object
- Decisions are records, not email threads. If it is not in the register, it did not happen.
- Lifecycle, not one-shot
- Material change reopens assessment. Monitoring loops back into governance rather than into a dashboard nobody reads.
- Policy as configuration
- Controls, questions and thresholds are versioned and changeable without a release. Regulation moves faster than software.
- Human oversight by design
- Oversight is designed at the start and evidenced in operation, not asserted in a policy document.
The lifecycle
Fifteen stages. Most programmes govern four of them and assume the rest take care of themselves.
| Stage | Scope | Governance output |
|---|---|---|
| Ideation | Before anything formal exists | Optional idea capture, so demand is visible before it becomes commitment |
| Intake | An idea becomes a submitted use case | Intake record, unique identifier, named sponsor and owners, initial classification |
| Triage | Lightweight filtering and routing | Tier, lane, applicable modules and overlays, service level started |
| Assessment | Depth proportionate to tier | Risk assessment, mitigation plan, reviewer sign-offs |
| Approval | A formal decision | Decision record with rationale, conditions and an expiry date |
| Build or procure | Delivery or acquisition | Technical documentation, model and system cards, data lineage, test records |
| Pre-release validation | Evaluation, red teaming, bias and security testing | Validation evidence and sign-offs proportionate to tier |
| Conformity | Where the system is high-risk and you are the provider | Conformity assessment, technical documentation, declaration of conformity, registration |
| Go-live | Production enablement | Owner acceptance, inventory activation, monitoring plan live |
| Operation and monitoring | Continuous | Telemetry, alerts, post-market monitoring, periodic attestations |
| Change | Material change, including silent vendor model updates | Change records and re-approval |
| Incident | Unexpected or harmful behaviour | Incident record, containment, root cause, remediation, regulator notification where required |
| Reassessment | Scheduled or event-driven | Reassessment record and renewed attestations |
| Retirement | Withdrawal from service | Decommissioning, data handling, documentation retention |
| Archival | Retention after retirement | Immutable archive of the full record for the required period |
Accountability
If a regulator, auditor or board asks who is accountable for a given AI system, the answer should take seconds. Accountability is not responsibility, which is shared, and it is not blame, which is punitive. It is the authority to act.
Named roles
- Business OwnerFirst line
- Business value, intended use, acceptable-use boundaries, and the continue, change or retire decision.
- Technical OwnerFirst line
- Engineering integrity in operation, incidents, change control, technical evidence. Holds authority to pause without convening anyone.
- Model or Agent OwnerFirst line
- Model selection, evaluation, fine-tuning, prompts, tool permissions, memory scope and content filters.
- Data OwnerFirst line
- Dataset quality, provenance, licensing, consent, retention and right to use.
- Risk and Compliance
- Ongoing conformance to policy and obligation, and the triggers that reopen assessment.
- Privacy Officer / DPO
- Lawful basis, impact assessments, data-subject rights, cross-border transfer.
- Security Officer
- Threat model, vulnerability management, access control, non-human identity, logging.
- Legal Counsel
- Contractual exposure, intellectual property, liability, regulatory interpretation.
- Independent Review
- Second-line challenge and assurance. Not the same people who built it.
- Executive Sponsor
- Ultimate accountability for high-risk systems and for the portfolio as a whole.
Three lines, adapted
- First line —
- Business and technology delivery — the four owner roles. Owns the system, the risk and the day-to-day decisions.
- Second line —
- Risk, compliance, privacy, security, responsible AI. Sets policy, challenges the first line, reports independently.
- Third line —
- Internal audit. Provides independent assurance that the first two lines work as described.
Moments that require a name
- — At intake, when owners are first named
- — At approval, when conditions are accepted
- — At go-live, when the owner formally accepts the system
- — At material change, including a vendor changing the model underneath you
- — At incident, when someone must have standing authority to stop it
- — At periodic review, when owners re-attest
- — At retirement, when someone confirms the data is handled correctly
The control framework
Nine themes, each mapped to the frameworks it satisfies. The mapping is the engine that absorbs regulatory change: when an obligation moves, you re-point a mapping rather than rewrite a programme.
Validity, reliability and robustness
The system does what it claims, at the quality it claims, under conditions it will actually meet.
- — Pre-release validation against a defined acceptance threshold
- — Benchmark and task-level evaluation with a versioned golden dataset
- — Regression suite covering prompts, retrieval configuration and model version
- — Drift detection on inputs and outputs with a defined response action
- — Safe failure behaviour — degrade or refuse rather than guess
- — Adversarial and stress testing proportionate to consequence
Safety and security
The system cannot be made to cause harm, and cannot become a route into everything behind it.
- — Threat model covering model theft, inversion, membership inference, data poisoning, prompt injection, supply chain and API abuse
- — Prompt-injection defence: input segregation, least-privilege tool access from the generative layer, output filtering, detection telemetry
- — Content filters and refusal behaviour tested, including jailbreak resistance
- — Kill-switch with named operators, tested on a schedule rather than assumed
- — Red teaming where the consequence of failure justifies it
- — Supply-chain assurance for models, weights, datasets and components
Fairness and non-discrimination
The system does not distribute harm unevenly across the people it affects.
- — Bias assessment before release, with the protected characteristics identified in advance
- — Sub-group performance measurement, not just aggregate accuracy
- — Mitigation applied and its effect measured rather than assumed
- — Residual bias documented and explicitly accepted by a named owner
- — Monitoring for divergence between sub-groups after release
Transparency and disclosure
People know when they are interacting with AI, and what it can and cannot do.
- — User-facing disclosure where a person interacts with the system
- — Marking of synthetic content and provenance signals where feasible
- — Model and system cards covering intended use, limitations and out-of-scope use
- — Published statement of what the system does not do
Explainability and contestability
A decision that affects someone can be explained to them, and challenged.
- — Decision-level explanation proportionate to consequence
- — Model logic and feature documentation retained
- — A route for an affected person to contest an outcome where law or decency requires it
- — Explanations tested on the people who will actually receive them
Privacy and data protection
Personal data is used lawfully, minimally, and does not leak back out of the model.
- — Lawful basis recorded before processing begins
- — Data protection impact assessment where required, and a fundamental rights impact assessment where the deployer is in scope
- — Minimisation at collection and at prompt construction
- — Memorisation and extraction testing for models trained or fine-tuned on personal data
- — Data-subject rights handling that works when the data is inside a model, not only inside a database
- — Cross-border transfer assessed, including where inference happens
Human oversight
A human can understand, intervene in and stop the system — in practice, not on paper.
- — Oversight mode chosen by rule rather than preference (see the oversight decision rule)
- — Named roles able to override, with overrides logged and reviewed
- — Automation-bias prevention: the interface must make disagreement easy
- — Oversight evidence captured as a record, so the control can be audited
- — Appeal path where the law requires one
Accountability and audit trail
Every consequential decision has a name against it and survives the people who made it.
- — Named owners maintained and re-attested on a schedule
- — Decisions, approvals, overrides and exceptions held as immutable records
- — Retention aligned to the longest applicable obligation
- — A point-in-time audit pack producible for any system on demand
- — Exceptions time-boxed, owned and reviewed — never open-ended
Generative and agentic surfaces
The risks that only appear once a system can generate, plan, remember and act.
- — System prompts and templates versioned, reviewed and change-controlled
- — Retrieval sources explicitly scoped; grounding verified as part of evaluation
- — Confabulation measured against a threshold, with high-stakes output verified before use
- — Vendor model updates treated as material change and revalidated
- — Agent autonomy classified, tool permissions whitelisted, memory scope bounded
- — Blast-radius containment on consequential actions
The oversight decision rule
Most frameworks say oversight should be "proportionate to risk" and stop there, which leaves the hardest question unanswered. This is a rule rather than a principle.
- In the loop
- A human approves each output before it has effect.
- Use when — The output is binding on a person, materially affects their rights, access, pricing or employment, or is effectively irreversible.
- On the loop
- The system acts; a human monitors and can intervene.
- Use when — The output influences a consequential decision but a person still makes it, or actions are reversible within a useful window.
- Over the loop
- The system acts; humans review samples and aggregate behaviour.
- Use when — Output is internal, low-consequence and reversible, and volume makes per-item review meaningless.
- Out of the loop
- No routine human involvement.
- Use when — Only where the worst realistic outcome is trivial and recoverable. If you cannot describe that outcome, you are not in this category.
Oversight that exists only in a policy document is not a control. If there is no evidence a human ever disagreed with the system, assume the oversight is decorative.
The obligation map
A risk tier tells you how much review to do. It does not tell you what you are required to produce. This does — and it is the part most intake processes leave out entirely.
- AI literacy
- Applies — Everyone. Providers and deployers alike, at every risk level, including fast-lane systems.
- Produce — Evidence that the people operating and overseeing the system have sufficient understanding to do so — role-appropriate training records, not a completion certificate.
- EU AI Act — AI literacy duty on providers and deployers
- Transparency to people
- Applies — Where a person interacts with the system, or where it generates or manipulates content they may take to be genuine.
- Produce — User-facing disclosure, and marking of synthetic content where feasible.
- EU AI Act — transparency obligations for certain AI systems
- Fundamental rights impact assessment
- Applies — Deployers of certain high-risk systems, notably public bodies and those providing essential services.
- Produce — A documented assessment of the effect on affected people’s rights, the mitigations, the oversight arrangements, and who is accountable.
- EU AI Act — fundamental rights impact assessment for deployers
- Conformity assessment and declaration
- Applies — Providers of high-risk systems, before the system may be placed on the market or put into service.
- Produce — Technical documentation, the conformity assessment route, an EU declaration of conformity, and CE marking where applicable.
- EU AI Act — conformity assessment for high-risk systems
- Registration
- Applies — High-risk systems, registered in the EU database before being placed on the market or put into service.
- Produce — A registration entry, kept current as the system changes.
- EU AI Act — registration of high-risk systems
- Quality management system
- Applies — Providers of high-risk systems.
- Produce — A documented quality management system covering design control, data management, testing, post-market monitoring and incident handling. ISO/IEC 42001 is the natural certifiable vehicle.
- EU AI Act — quality management system; ISO/IEC 42001
- Post-market monitoring
- Applies — High-risk systems, for the whole time they remain in service.
- Produce — A monitoring plan and the evidence it ran — metrics, thresholds, actions taken, and feedback into reassessment.
- EU AI Act — post-market monitoring
- Serious incident reporting
- Applies — Providers of high-risk systems, on becoming aware of a serious incident or malfunction.
- Produce — A reporting route to the relevant authority with a defined internal clock, plus the record of what was reported and when. Build the route before you need it.
- EU AI Act — reporting of serious incidents
- Record-keeping and logging
- Applies — High-risk systems, with automatic logging over the system’s lifetime.
- Produce — Automatically generated logs retained for the period required, and documentation retained after the system is withdrawn.
- EU AI Act — record-keeping and documentation retention
- Human oversight
- Applies — High-risk systems, designed so oversight is effective rather than nominal.
- Produce — Oversight design, named roles able to override, and evidence the override has been exercised.
- EU AI Act — human oversight for high-risk systems
- General-purpose model obligations, inherited
- Applies — Anyone building on a third-party foundation model. The provider’s obligations do not become yours, but their documentation is how you discharge your own.
- Produce — The model provider’s technical documentation, acceptable-use terms, training-data summary where published, and a contractual route to notification of model change.
- EU AI Act — general-purpose AI model obligations
- Retention versus minimisation
- Applies — Any high-risk system processing personal data.
- Produce — A documented position reconciling long record-retention obligations with data-protection minimisation — typically by separating the decision record from the personal data that informed it.
- EU AI Act record-keeping, read with GDPR minimisation
Generative risk categories
The twelve categories from the NIST Generative AI Profile. Useful as a completeness check: if your assessment template cannot locate a question against each of these, it has a gap.
01CBRN information or capabilities
Lowered barriers to chemical, biological, radiological or nuclear weapons information.
02Confabulation
Confidently stated false content, delivered in the same tone as correct content.
03Dangerous, violent or hateful content
Easier production of radicalising, violent or threatening material.
04Data privacy
Leakage of personal data memorised in training; inference of sensitive attributes.
05Environmental impacts
Energy and resource intensity of training and inference.
06Harmful bias and homogenisation
Amplification of bias and convergence of outputs toward a narrow range.
07Human-AI configuration
Over-reliance, misplaced trust and poorly designed oversight.
08Information integrity
Misleading content and synthetic media at scale.
09Information security
Prompt injection, data poisoning, model theft, AI-assisted attacks.
10Intellectual property
Use or reproduction of protected material without permission.
11Obscene, degrading or abusive content
Including non-consensual intimate imagery.
12Value chain and component integration
Risk inherited from third-party models, data and components you cannot see into.
The part most frameworks miss
Governing agents
Agentic governance assumes agents will occasionally be creative in unproductive ways. Controls therefore constrain blast radius, not just intent — because intent is the thing you cannot inspect.
Autonomy is the first classification
Assistive
Proposes; a human does everything.
Treat as a generative system. Oversight in the loop by construction.
Supervised
Acts within a narrow scope, each action confirmed.
Tool permissions whitelisted. Confirmation cannot be bulk-approved.
Delegated
Completes multi-step tasks; a human reviews outcomes.
Blast-radius limits, transaction caps, full action logging, tested kill-switch.
Autonomous
Plans and acts continuously without routine human involvement.
Independent review before release. Sandbox by default. Named operator on call.
The agentic controls
- Autonomy classification
- The single most important governance input for an agent. Classify before anything else, because it determines every other control.
- Agent identity
- A dedicated non-human identity with scoped credentials, rotation and revocation. An agent sharing a human’s credentials is unauditable.
- Tool permissions
- Explicitly whitelisted and least-privilege. A new tool is a change requiring approval, not a configuration tweak.
- Memory governance
- Ephemeral, session and long-term memory categorised, with policy bounding what may be retained and for how long.
- Transaction limits
- High-impact actions bounded by amount, count or category, and reducible immediately on anomaly.
- Blast-radius containment
- Data-modifying actions reversible by default. Anything irreversible requires explicit approval at design time, not at runtime.
- Multi-agent orchestration
- Which agent may call which, the message policy between them, how trust propagates, and how a compromised sub-agent is contained.
- Human checkpoints
- Mandatory confirmation for consequential actions, placed where a human can still realistically intervene.
- Behaviour monitoring
- Agent behaviour as a time series. Anomalies investigated rather than averaged away.
- Kill-switch
- Disables cleanly without corrupting state. Tested periodically. Operators named in advance.
- Sandboxing by default
- New agents run contained. Promotion to production scope requires sign-off.
Finding what never came through the door
Shadow AI (unsanctioned use) and ambient AI (quietly embedded by vendors into tools you already bought) are the largest real exposure in most organisations, and neither arrives through the front door. A governance programme that only governs what is submitted to it is measuring its own inbox.
| Method | What it surfaces |
|---|---|
| Procurement and expense analysis | Paid AI tools bought on cards or through departmental budgets, below approval thresholds. |
| SaaS and network telemetry | Traffic to model APIs and AI services from managed devices, including from applications you did not know called them. |
| Identity and OAuth grant review | AI tools granted access to corporate data through single sign-on or third-party app consent. |
| Vendor disclosure requests | Ambient AI already shipped into existing platforms — often the largest category and the least visible. |
| Code and repository scanning | Model SDKs, API keys and inference calls embedded in internal applications. |
| Periodic amnesty | Everything the above misses. Run without blame, or it returns nothing. |
Discovery is a capability with an owner and a cadence, not a one-off audit. The number that matters is the ratio of discovered to submitted — if it is not falling, the front door is not working.
Where are you now
Five levels. Most organisations that believe they are at level three are at level two, because the test is not whether rules exist but whether they hold when everyone is busy.
- L1Ad hoc
- AI decisions are made case by case by whoever is in the room. No inventory. No consistent intake.
- Residual risk — You cannot answer "how many AI systems do we run" or "who owns this one".
- L2Documented
- A policy exists and an intake form exists. Routing is manual and inconsistent. Inventory is a spreadsheet.
- Residual risk — Governance depends on individuals remembering. It degrades the moment they are busy.
- L3Operating
- Risk-proportionate triage with published rules. Named owners. Decisions held as records. Periodic review by tier.
- Residual risk — Still reactive to regulatory change; still weak on discovery of what never came through intake.
- L4Measured
- Controls mapped to frameworks. Monitoring feeds back into governance. Metrics with targets. Discovery running continuously.
- Residual risk — The remaining gap is usually agentic systems and third-party model change.
- L5Adaptive
- Policy-as-configuration absorbs regulatory change. Evaluation is automated and versioned. Agent behaviour monitored as a time series. Assurance is independent.
- Residual risk — The failure mode becomes complacency — treating the framework as finished.
Measuring the programme
| Metric | Measure | Target |
|---|---|---|
| Intake cycle time | Submission to decision, by tier | Fast lane under 10 working days |
| Discovered-to-submitted ratio | Systems found by discovery versus systems submitted | Falling quarter on quarter |
| Inventory completeness | Systems with all four owner roles named and current | Above 95% |
| Attestation currency | Systems whose periodic review is in date | Above 90% |
| Exception ageing | Open exceptions past their expiry | Near zero |
| Evaluation coverage | Production systems with a current pre-release evaluation and regression suite | Above 90% for medium and high tiers |
| Incident detection time | Behaviour change to detection | Hours, not weeks |
| Oversight evidence rate | Share of in-the-loop systems with recorded human disagreement | Non-zero |
- Intake cycle time —
- The best predictor of whether teams use the front door or route around it
- Discovered-to-submitted ratio —
- The honest measure of whether intake has authority
- Inventory completeness —
- If you cannot name owners, nothing downstream is reliable
- Attestation currency —
- Stale attestations mean the register describes a past organisation
- Exception ageing —
- A growing exception register means the policy is wrong, not that teams are
- Evaluation coverage —
- Distinguishes governance that tests from governance that asks
- Incident detection time —
- Especially for silent vendor model updates
- Oversight evidence rate —
- If humans never disagree with the model, the oversight is decorative
Anti-patterns
- The policy without a register
- Looks like — A well-written AI policy, no inventory of AI systems.
- Costs you — Nothing is enforceable, because nothing is enumerated.
- Governance by committee calendar
- Looks like — Every use case waits for a monthly forum regardless of risk.
- Costs you — Teams route around it, and you lose sight of the riskiest work first.
- The ethics board with no teeth
- Looks like — A senior panel that advises but cannot stop anything.
- Costs you — Deliberation without consequence, which trains everyone to treat it as theatre.
- Model-centric thinking
- Looks like — Governing the model and ignoring the prompt, retrieval sources, tools and memory around it.
- Costs you — The model is rarely what fails. The scaffolding is.
- One-shot assessment
- Looks like — Approved at go-live, never revisited. Vendor changes the model silently.
- Costs you — Your approved system is not the system now running.
- Shadow-blind governance
- Looks like — Governing only what is submitted.
- Costs you — You are measuring your own inbox while the exposure sits outside it.
- Compliance as the ceiling
- Looks like — Controls stop exactly where the regulation stops.
- Costs you — Regulation is a floor written for the last generation of systems. It will not cover your agents.
Common questions
- What is an AI intake process?
- An AI intake process is the single structured front door through which every proposed or discovered AI use case enters formal governance. It captures the context needed to understand the proposal, classifies its risk, routes it to the right depth of review, and ends in a documented decision. It handles both submitted intake, where a person proposes something, and discovered intake, where scanning, procurement data or vendor disclosure surfaces AI that never came through the door.
- How do I know if my AI system is high-risk?
- Work through the classification dimensions in order. The decisive questions are whether the output determines an outcome affecting a person’s rights, access, livelihood or safety; whether special-category personal data is involved with real-world effect; whether the worst realistic error causes harm to health, safety or fundamental rights; and whether the system acts autonomously in ways that are hard to reverse. Any one of those routes the system to the high-risk lane. A prohibited-practice screen runs first and overrides everything.
- What is the difference between an AI provider and an AI deployer?
- A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority. The obligations differ substantially — conformity assessment, registration and serious-incident reporting largely fall on providers, while fundamental rights impact assessment and operational oversight fall on deployers. Putting your own name on a third party’s system can make you the provider.
- Who should be accountable for an AI system?
- Four named individuals, not teams: a business owner accountable for value and intended use, a technical owner accountable for operational integrity and holding standing authority to pause, a model or agent owner accountable for model selection, prompts, tool permissions and memory, and a data owner accountable for provenance, licensing and right to use. Second-line functions challenge and report; internal audit assures. Risk accepted by a committee is risk accepted by nobody.
- What is shadow AI and how do you find it?
- Shadow AI is unsanctioned use; ambient AI is capability quietly embedded by vendors into tools you already bought. Neither arrives through the front door, and together they are the largest real exposure in most organisations. Discovery combines procurement and expense analysis, network and SaaS telemetry, identity and OAuth grant review, vendor disclosure requests, repository scanning, and periodic blameless amnesties. The number that matters is the ratio of discovered to submitted — if it is not falling, the front door is not working.
- How should agentic AI be governed differently?
- Classify autonomy first, because it determines every other control. Then give the agent its own non-human identity with scoped credentials, whitelist its tools under least privilege, bound what it may remember, cap consequential transactions, and contain blast radius so data-modifying actions are reversible by default. Agentic governance assumes agents will occasionally be creative in unproductive ways, so controls constrain blast radius rather than relying on intent — because intent is the thing you cannot inspect.
- When should a human be in the loop rather than on the loop?
- In the loop, meaning a human approves each output before it has effect, where the output is binding on a person, materially affects rights, access, pricing or employment, or is effectively irreversible. On the loop, where the output influences a decision a person still makes, or where actions are reversible within a useful window. Over the loop, with sample and aggregate review, where output is internal, low-consequence and high-volume. Oversight that leaves no evidence of a human ever disagreeing with the system is decorative.
- Does the EU AI Act apply to organisations outside the EU?
- Yes, in defined circumstances. The Act reaches providers and deployers established outside the EU where the output produced by the system is used within the EU. Organisations frequently assume they are out of scope on the basis of where they are headquartered, which is the wrong test.
Free to adopt, adapt and cite with attribution to Shailesh Kumar (vantessence.com). Independent, with no affiliation to any employer, vendor or standards body. This is an operating model, not legal advice — obligations are described by category and every date-dependent detail should be verified against the primary source.