Overview

Summary

The use of AI has moved from a small number of projects each year to agents built continuously, by many people, on several platforms. Agents do more than answer questions: they call tools, read and write data, and initiate processes. They are assembled from shared components (a platform, a model, connectors, skills, knowledge sources), and those components change independently of the agent, often without its owner's knowledge.

Governance designed for occasional AI projects does not provide assurance under these conditions. Registers maintained by hand become outdated; the same facts are entered into a questionnaire, a register, a risk template and a GRC tool; self-declared answers determine the level of scrutiny; and an approval, once given, does not reveal later changes to instructions, models or tools.

The framework establishes one lifecycle for every AI asset, with defined decisions, owners and evidence, proportionate to risk. Responsibility is organised in three pillars: Adopt builds and runs, Defend tests and protects, Govern approves and oversees. The framework is designed to be operated with automated technology rather than documents and e-mail, and does not assume a particular product.

The framework at a glance

Key messages

1. Governance centres on the assets that produce outcomes. Agents, AI-enabled systems and platforms take the full lifecycle. Models, tools, skills and knowledge sources are their building blocks: assessed once, reused many times, and governed through their uses.
2. One lifecycle, three decisions: the initial approval (may it be built or bought?), the deployment approval (may this configuration go live?), and continuous oversight in production (may it remain live?).
3. The go-live requirements are known at the start. The initial approval sets the path, the controls and the test scope before money is spent.
4. An approval applies to a configuration. Planned change is declared before it is made; other change is detected; a substantial modification is assessed and approved again.
5. Governance effort is proportionate to risk. The change materiality determines the path; the level of autonomy determines the minimum controls.
6. Building, testing and approving are separate. Whoever builds an asset does not validate it, and neither approves it. Security is tested by an AI security team and challenged independently by the CISO.
7. Information is collected rather than submitted, and automation does the routine. What an AI platform can report is read from it; what people declare is verified against what is discovered; an AI assistant pre-fills the forms, checks what is submitted and prepares decisions; routine outcomes are settled by rule and recorded. People decide.
8. Each asset has one record, which cannot be rewritten. Every fact, decision and change is kept with who, when and on what evidence, and can be produced as it stood on any date.

Section 16 describes how an organisation can adopt the framework.

In the framework: section 1.

Part I · The lifecycle in practice

1. What is governed

The eight classes

Out of scope [to be confirmed]

An employee's personal-productivity use of an approved general-purpose tool (for example, asking Copilot to draft an e-mail) is governed by the [acceptable-use policy], not asset by asset; the tool itself is registered and governed. Software without AI is out of scope.

Why agents require their own lifecycle

Key terms

In the framework: sections 2 and 3, and Appendix A.

Part I · The lifecycle in practice

2. The lifecycle at a glance

The nine stages

The component track

A model, tool, skill or knowledge source is registered, assessed on what matters for its class, and approved for reuse. From then on it is governed through its uses: each agent that connects to it asks its owner where its policy requires, and each change to it reaches those agents (section 3, Components).

The path

The owner's answers at Gate 1 give the change materiality from three facts: the EU AI Act risk class, the process impact (how much the AI changes the business process: assistive, influencing or transformative) and the process criticality (critical, important or other). The materiality sets the path:

A prohibited practice under the EU AI Act is never approved. On every path, the level of autonomy adds minimum controls, and personal data, read or generated, involves the DPO. Section 9 sets out the method.

Roles in the lifecycle

In the framework: sections 7 and 6.2.

Part I · The lifecycle in practice

3. Deploying a new AI system or agent

The seven steps

The four assessments at step 2

What go-live requires (step 6)

The test report, the change risk assessment and the other evidence of the path (section 2, The path). In addition, on every path: the controls of the level of autonomy, with evidence (a conditional agent: authority statement, logged actions, a way to stop it, the platform's guardrails on; an autonomous agent also: a human go-live decision, logs that can replay what it did, limits on runaway actions, re-tests on a schedule, a fairness evaluation where it affects people); where personal data is involved, the DPIA's measures in place and the record of processing linked; for a high-risk system, technical documentation, independent validation of the model, record keeping and a FRIA where required. Where a platform cannot yet provide a control, the approval records the gap as a condition with an owner and a date.

Buying rather than building

A bought product is assessed at its product and version, always with the organisation's own assessment, including security. Vendor documents are kept as evidence with their validity. Who controls what depends on the deployment class:

Components

A component is registered, assessed on what matters for its class and approved for reuse once; agents built on it inherit the assessment.

Effort and time

[Targets to be calibrated in the pilot.] The owner's time to register and assess is [under 30 minutes] on Light and [under 2 hours] on Standard, a DPIA excluded; the Gate 1 decision follows a complete registration within [2], [5] or [10] working days by path. Light needs no meeting; Standard one risk workshop, which can be held in writing; Enhanced the risk workshop and [the Council]. On the Light path, Gates 1 and 2 can be one decision.

In the framework: sections 6, 7.3, 8.1 to 8.6 and 11; Appendix B.

Part I · The lifecycle in practice

4. When an AI system or agent changes

What the owner does

1. Declares a planned change before making it, on the screens or, from a pipeline, through the API. A pipeline can ask what a change would mean for the asset's classification and obligations, and whether a version is approved, before it deploys.
2. Acts on the outcome of triage (below).
3. For a substantial modification or a new use: completes the assessments again where facts changed, has the changed configuration tested, and obtains approval by its path before it goes live.
4. Keeps owners, connections and documentation current, meets the conditions of approval, and confirms the asset at each periodic review.

How changes arrive

The four outcomes

Triage rules flag a change for attention when, for example, a tool of a higher tier is added, the model changes, data access widens, the audience grows or a guardrail is removed. The examples in brackets are illustrative; the rules are configuration, calibrated in the pilot.

What is a substantial modification

A change that alters the purpose, the level of autonomy, the people affected, the data sources, the model or the documented controls. The triage signals point to the answer: a new model, wider data access, a larger audience or a tool of a higher tier usually is one. Retraining within validated limits, configuration that leaves the purpose unchanged, and maintenance are not substantial [as the change risk management standard defines]. Use in a new business process or for a new purpose is a new change. A change that touches personal data (a new data source, new people affected, a new model or vendor) also repeats the personal data screening.

When a component changes

Monitoring and periodic review

A change nobody declared can be escalated to the AI Governance Officer at once (section 5). Meanwhile the governance solution watches, automatically, whether the approved controls are still on, whether the live configuration still matches the approved one, and whether evidence and approvals are still valid, and turns what it finds into tasks before anything lapses; the AI security team monitors behaviour at runtime with its own tools. Periodic review renews the approval at the frequency of the path. It arrives pre-filled: the AI assistant summarises what changed, what was found and how the asset is used, and points to facts that no longer match what is observed, such as a larger audience; the owner confirms, in one step, what has not changed.

In the framework: sections 7.3 and 8.7.

Part I · The lifecycle in practice

5. When something goes wrong, and retirement

Triggers for escalation

An unregistered agent found running; a change nobody declared; drift from the approved configuration; a required control switched off; a condition of approval not met; an overdue review or task; a runtime finding or an AI incident; a problem announced for a vendor product. Automation detects each of them: the connectors the first four, rules the unmet conditions and overdue work, the security tools and [incident management] the runtime findings and incidents, and the vendor watch the problems of vendor products. People can raise any of them as well.

Escalation path

Owner → owner's manager → AI Governance Officer → AI Governance Council, which may decide to suspend the asset. Where a step does not act in time, the escalation moves to the next one by rule. The suspension is carried out on the platform by the technical owner or the platform team, with the stop that the authority statement names.

Handling an AI incident

Retirement

Decided by the owner, or by the Council after an escalation. Assets that depend on the retired one are informed; connections are ended; access and identities are removed on the platforms; personal data held for the asset is deleted or kept as the DPIA and the retention policy require; lessons are recorded. The asset and its record remain readable for any earlier date. Automation proposes retirement for an agent unused for [90 days], left without an owner, or built on a model or product out of support; on retirement it informs the dependants, ends the connections, opens the tasks to remove access, and confirms through the connectors that the agent is off. An agent that reappears is treated as unregistered. The AI assistant drafts the lessons from the asset's incidents, findings and conditions.

In the framework: sections 8.8, 8.9 and 9.

Part I · The lifecycle in practice

6. Who does what, and what each function receives

In the framework: sections 5, 7.2 and 10.

Part I · The lifecycle in practice

7. Automation and the AI assistant

Automation in the lifecycle

In the tables of sections 3 to 5, Automatic marks work done by rules, connectors, pipelines or tools that people configured in advance, recorded with the rule or tool and its version; AI assistant marks work that the AI assistant drafts or checks, and a person confirms.

What the AI assistant does

The AI assistant is itself a registered AI asset, at the assistive level of autonomy: it reads only what the person it works for may see, its tools only read, and nothing it produces changes the record until a person confirms it (principle 7). It uses a model the organisation chooses and is off until the organisation switches it on; everything works without it.

For pipelines and coding agents

Registration and updates through the API [and MCP] with a machine-readable declaration, as part of the build; the questions "what would this change mean?" and "is this version approved?" before deployment; test results delivered to the asset. They act under the same permissions as a person, on behalf of an accountable person, and in the same record.

What remains with people

• The decisions at the gates
• Whether a change is a substantial modification
• Red teaming, judging findings and the CISO's challenge
• The DPIA, the change risk assessment and the acceptance of risk
• Suspension, return to production and retirement

In the framework: section 11.

Part II · The governance model

8. Operating model

The AI Governance Council

[Composition: head of AI governance (chair), lead of the AI security team, CISO, Chief Risk Officer or delegate, DPO, Compliance and Legal, CIO / CTO or delegate, a business representative.] The Council:

• decides go-live on the Enhanced path;
• resolves disagreements between those who build and those who test [without overruling a veto of the CISO on security grounds, where the information security policy provides one];
• sets the thresholds specific to AI: the minimum controls per level of autonomy and, once the CISO has approved it, the testing standard. The change materiality method comes from [the change risk management standard], to which the Council proposes changes;
• is the final level of escalation, and decides on suspending an asset and on its return to production.

Further roles

• Beyond those of section 2: Risk (second line: risk appetite, the change materiality method, the change risk assessment, model validation)
• Compliance and Legal (second line: EU AI Act role and class, prohibited practices)
• Internal Audit (third line: independent assurance, with access to the whole record and any past date)
• [the privacy function] (supports owners in the screening and the DPIA
• Keeps records of processing)
• The AI Governance Manager (register quality, reassignment, overdue work)
• The administrator (configures classes, forms and workflows, and cannot weaken safeguards unseen)
• automation (section 7: rules and workflows, connectors and the AI assistant with Govern, pipelines and coding agents with Adopt, test and security tools with Defend
• Each kind has an accountable owner, does work and never signs off)

The responsibility matrix

Separation of duties and effective oversight

The approver is never the requester, and the validator is never the builder. A second person publishes every change to workflows and forms. Approvers receive a prepared task with the asset, its assessments, documentation, connections and history in one place. Approval rates and review times are monitored, and unusual patterns, such as approvals given in seconds, are reviewed by sampling, so that volume does not turn oversight into a formality.

In the framework: section 5.

Part II · The governance model

9. Proportionality: the method

9.1 Change materiality

A change is a new asset, a new use of an approved asset, or a substantial modification of an asset in use. Its materiality is rated at Gate 1 and again whenever the asset or its use changes substantially, as [the change risk management standard] defines.

Adjustments, which can only raise the result

A customer-facing asset is at least Medium; reclassification to high risk makes it Significant; a high or critical residual risk found in the change risk assessment makes it Significant; where several kinds of change coincide (for example, with a new ICT system or third-party agreement), the highest materiality applies. The organisation's change risk management standard prevails where it differs.

Rules

The owner rates the materiality; governance reviews it at Gate 1. Anyone may raise the path; lowering it below the method's result requires a recorded reason [approved by the owner of the change risk standard]. Neither personal data nor the level of autonomy changes the path: each has its own requirements on every path. The requirements for a high-risk system follow its risk class, whatever its path. The values are starting points, calibrated in the pilot and held as configuration.

9.2 The paths in full

9.3 Minimum controls per level of autonomy

The level of autonomy concerns how far a person is in the loop; the process impact concerns the business process. The two are rated separately. Where a platform cannot yet provide a control, the approval records the gap as a condition with an owner and a date.

9.4 Trust tiers of tools and MCP servers

The tier is stated at registration and confirmed by the AI security team. An agent acting through a tier 2 or 3 tool usually executes process steps itself, which makes its process impact transformative. Instructions returned by a tool are never treated as instructions.

9.5 The data protection route

The route applies on every path whenever an asset processes personal data or may generate it, for example a summary of a customer's complaint or an inference about a person's income or health. An unanswered question counts as yes.

In the framework: section 6.

Part II · The governance model

10. Testing standard

Classes of harm

Depth of testing by path

On every path, in addition: personal data (disclosure only to those entitled, retention as set, accuracy about real people); controls of autonomy by level (the authority statement holds, the stop works, limits halt runaway actions, the logs replay what it did); operational readiness (monitoring, guardrails, fallback and a way back).

What is assessed, and when

How a test is passed

Criteria are set at Gate 1, before results are known. Findings are rated [critical · high · medium · low]; critical and high findings block go-live until fixed and re-tested; the others become conditions or accepted risks with an owner and a date. One signed test report per candidate configuration states the configuration tested, the scope, the results by harm, the findings and the known limitations, which are passed on to users. The CISO samples reports and challenges them. The AI security team drafts the standard, the CISO approves it, and the Council adopts it; it is reviewed every year.

In the framework: section 8.4 and Appendix D.

Part II · The governance model

11. Monitoring, incidents and evidence

Governance monitoring

AI incidents

The governance solution links an incident to the asset, so that the question "which agents use this model, tool or knowledge source, and what was approved for them" is answered in minutes.

In the framework: sections 8.7 and 9.

Part II · The governance model

12. Principles, safeguards and guardrails

The thirteen principles

Safeguards and protections

Guardrails on automation

• Automation proposes and never grants: declared or imported data never sets a classification, an approval or a rule on its own. It does work and never signs off, and every kind of automation has an accountable owner.
• Every automatic outcome is recorded with the rule or tool and its version that produced it, and governance samples such outcomes as it samples approvals. Rules are configuration, published by a second person.
• Nothing the AI assistant produces changes the record until a person confirms it. The share of its suggestions accepted unchanged, and the time taken to confirm them, are monitored, so that confirming does not become a formality.
• The separation of duties applies to automation: a test suite in the builder's pipeline is the builder's evaluation, and counts as the AI security team's test only where that team owns the suite, its thresholds and its run.
• Containment is automatic only for the cases the AI Governance Council has authorised in advance; each use is reviewed.

In the framework: sections 4 and 11.5.

Part II · The governance model

13. Supporting technology, security and privacy

What the governance solution must do

Not its task

Runtime monitoring of agents, security testing, prompt or output filtering, routing of model traffic, incident management. These are controls of the organisation, run with its own tools; the governance solution records that they are in place, holds the evidence and escalates when they are not.

Integration

• The change risk assessment of a Medium or Significant change runs in [the GRC tool], linked to the asset
• Identifiers are mapped to [the CMDB]
• Dependency data is supplied to [third-party risk]
• Incidents remain in [incident management]
• DPIAs and records of processing are linked from [privacy management]
• The audit trail is supplied to [the SIEM]

Selection

The options are a dedicated AI governance product, an extension of an existing GRC tool, or a solution built or adapted in-house. They are compared on how much of the requirements they meet by configuration rather than custom code, discovery of the AI platforms in use, openness to pipelines and coding agents, where the data is held, security and privacy, and cost of ownership against the effort saved.

AI-specific risks

Security of the governance solution

• Data under the organisation's control
• Sign-in through its identity provider with multi-factor authentication
• Read-only connectors with their own credentials and explicit permissions
• Secrets protected with a key the organisation controls
• Uploaded files scanned
• Content read from AI platforms treated as untrusted data
• An append-only, tamper-evident audit trail that can be verified externally
• AI assistance off until enabled
• A maintained threat model and an independent penetration test before production use

Privacy of the governance solution

• It holds little personal data (names, e-mail addresses and sign-in names from the directory, and what people write about assets)
• The audit trail records pseudonymous identifiers
• E-mails carry the asset's code and name, what is asked, by when, and a link, never answers or comments
• Its own AI features are governed like any other AI asset
• Erasure requests are met without breaking the immutable record [to be settled with the DPO]

In the framework: sections 12 and 13.

Part II · The governance model

14. Regulatory alignment

In the framework: Appendix E.

Part II · The governance model

15. Implementation roadmap

The six phases

Measures of success

Prerequisites

• Agreement on the framework
• Named people for the roles and the Council
• Once the technology is chosen, read-only access to the AI platforms, directory integration, a hosting environment and the pilot scope

In the framework: the implementation roadmap.

Part II · The governance model

16. Adoption of the framework

An organisation adopting the framework typically proceeds as follows:

1. Adapt the framework: replace the placeholders in square brackets with the organisation's own committees, functions and tools, and align the change materiality with its change risk management standard.
2. Establish the AI Governance Council and staff the three pillars.
3. Settle the points that shape the choice of technology: integration with the existing GRC, CMDB, third-party risk and incident tools, and the retention of governance records.
4. Select the supporting technology against the requirements of section 13.
5. Pilot the lifecycle on real assets, and calibrate the paths, controls and effort targets.
6. Connect the AI platforms in use, and operate the full lifecycle.

Reference

Abbreviations

Reference

Licence

© 2026 Andres Gavriljuk. Licensed under the Creative Commons Attribution-NonCommercial 4.0 International licence (CC BY-NC 4.0). It may be shared and adapted for non-commercial purposes, with attribution. For commercial use, ask the author.

Attribution: Andres Gavriljuk, "Agentic AI Implementation and Lifecycle Governance: Executive overview", version 1.1, 2026, https://github.com/pragmatiqai/governanceframework, CC BY-NC 4.0.

OWASP, MITRE ATLAS and the other frameworks and products named belong to their owners. They are referred to, not reproduced.