CI-AIGAF EU-TEL

A note to the reader: read this as a framework, not as a compliance manual

This handbook is written for a person who may be seeing CI-AIGAF EU-TEL for the first time and who may then need to explain it to colleagues in operations, engineering, security, legal, privacy, assurance or management. The aim is not to make the reader memorize a catalogue of codes. The aim is to make the operating logic understandable: when AI is allowed to influence or control telecommunications, the authority given to that system should never exceed what the organization can justify with current evidence, appropriate human and technical controls, and the law that applies to the actual deployment.

Telecommunications organizations already know how to run controlled change, incident management, access management, resilience, audit, supplier governance and regulatory reporting. AI does not replace those disciplines. It introduces new uncertainty into them: model behaviour can change with context; agentic systems can chain actions through tools; human approval can become nominal when machines act faster than people can understand; supplier updates can invalidate earlier testing; and a system that is legally outside one high-risk category can still be operationally dangerous. CI-AIGAF EU-TEL is designed to connect these realities into one authorization and evidence model.

Why this document is useful

The document creates a common language between teams that normally see different parts of the same AI deployment. Network Operations may see a change mechanism. AI Engineering may see a model and tool chain. Security may see privileged identities. Legal may see provider/deployer roles and statutory obligations. Privacy may see personal or communications data. Internal Audit may see control effectiveness. Senior management may see service, regulatory and reputational exposure. CI-AIGAF EU-TEL gives those teams one shared object: the permission to operate a specific deployed AI system within a bounded authorization envelope.

It also prevents a common failure of governance programs: treating “compliant”, “tested”, “approved” or “human in the loop” as permanent labels. In this framework, authority is conditional. If evidence expires, supplier changes alter the system, monitoring stops, a critical assumption fails, or an incident reveals a new hazard, the system can lose authority even if a previous approval document still exists.

The handbook is therefore useful before procurement, during design, before production release, during daily operations, when a system changes, after an incident, during audit, and when an operator expands the same capability into another Member State. The same framework is used throughout the lifecycle so teams do not have to reinvent governance at each stage.

Who should use it

Why an organization would follow the framework

There is no legal rule that says a telecom operator must adopt a framework named CI-AIGAF EU-TEL. The reason to follow it is operational: applicable EU and national obligations arrive through different regimes, while the production system is one connected socio-technical system. Without a unifying method, classification, access, supplier evidence, testing, human oversight, incident handling, privacy, change control and authorization can become separate compliance workstreams that do not actually constrain production behaviour.

CI-AIGAF EU-TEL is designed to make those workstreams converge on operational permission. It asks a simple but demanding question: “Given what we know now, what is this exact AI deployment allowed to do?” The answer must be traceable to the system boundary, applicable law, operational authority, plausible consequence, evidence quality, human and technical controls, lifecycle gate decisions and the current authorization envelope.

How to read this handbook without getting lost

1. Read the opening and Part I to understand the operational problem. Do not start with the codes.
2. Use Part II to learn the five questions. The codes are simply shorthand for answers to those questions.
3. Read Part III as a story. It follows one AI Network Change Agent from idea to production, change, incident and reauthorization.
4. Use Part IV to understand what your function is expected to contribute and what it should not approve by itself.
5. Use Parts V-VIII for the legal, evidence, runtime and enterprise operating model.
6. Use Part IX only when you need the detailed reference: G0-G9, P1-P18, instruments, use-case catalogue and application/control-plane mapping.

Part I — The problem before the framework

1. Start with an operational story, not with a regulation

A telecom operator introduces an AI Network Change Agent. The first release is conservative: it reads alarms, topology and previous change records, then drafts a proposed configuration change. An engineer reviews the proposal and manually enters the approved commands. The pilot performs well, so the team connects the agent to a change API. It can now submit changes for approval. Later, the supplier offers an “autonomous mode” that can execute within defined thresholds. The product name did not change, but the operational system did.

Now imagine the agent recommends a change that destabilizes a cluster. One service is degraded and emergency-service traffic protection is affected. The engineer who approved the change relied on a generated explanation that omitted a dependency introduced the previous week. A supplier model update had also been installed three days earlier. The organization must now answer questions that a conventional model card cannot answer.

• What exact version, prompt/RAG configuration, tool set and permissions were operating?
• Was the system acting as a recommender, a submitter or an executor?
• What network domains and protected services were inside or outside its authorization?
• What evidence had been accepted, and did that evidence cover the current topology and supplier version?
• Could the human overseer realistically understand and intervene before the change became irreversible?
• Which legal roles and obligations applied to this deployment and to the organization?
• Which incident routes and reporting clocks might now be relevant?
• What evidence must be frozen so the decision can later be reconstructed?
• Who has authority to keep the system running, reduce it to advisory-only, suspend it, recommission it or retire it?

CI-AIGAF EU-TEL is designed so these answers are created before they are urgently needed. The framework makes the decision path explicit, binds evidence to the deployed system and version, and treats production authority as a controlled state rather than a one-time approval.

2. Why traditional AI governance can be too abstract for telecom operations

Many AI governance frameworks are good at defining principles, risk themes and management responsibilities. Telecom operations need an additional layer: a way to translate those principles into executable limits in environments where machine decisions can touch live network infrastructure, customer services, identity systems, routing, resilience and emergency communications.

The key shift is from model governance to authority governance. The relevant object is not just a model. It is a deployed socio-technical system: model, prompts, RAG sources, data, tools, agent logic, identities, network interfaces, users, human reviewers, supplier components, operating procedures, country and service context. Two deployments of the same commercial model can therefore need completely different legal and operational treatment.

This is also why a compliance percentage is a weak operating signal. A system can be “95% compliant” and still be unsafe to operate if its authorization expired, a blocking piece of evidence is missing, the human overseer is unavailable, or a supplier change invalidated earlier tests. CI-AIGAF EU-TEL gives blocking conditions priority over aggregate scores.

3. The operating principle in one sentence

This principle has practical consequences. If an AI system has only been tested as a recommender, the evidence does not justify autonomous execution. If testing covered one topology, it does not automatically justify operation across all network regions. If the human approval step cannot occur before an irreversible action, it should not be credited as effective human oversight. If a supplier model update changes behaviour, the previous evidence must be screened for continued validity. If the system is legally non-high-risk, that does not erase operational risk.

Part II — Understand CI-AIGAF EU-TEL through five questions

The easiest way to learn the framework is to ignore the acronyms for a few pages. Every deployment must answer five questions. The formal codes are introduced only after the question is understood.

4. What does the law say about this actual use?

The legal route depends on what the system is, how it is used, the role held by the organization, the affected people or infrastructure, the country, and the date. The EU AI Act is central but not alone: telecom operations may also engage NIS2, GDPR, ePrivacy, the EECC, the Open Internet Regulation, accessibility, consumer, employment, resilience or product rules. CI-AIGAF EU-TEL records legal status separately because a legal label should not be asked to carry the whole operational risk decision.

5. What can the AI really do?

Authority is about deployed capability. Can the system only retrieve information? Can it recommend? Can it submit a change? Can it execute through a tool? Can it chain several tools? Can it act without a human approval? Does it hold privileged credentials? The framework represents this operational authority on A0-A4. The exact tier definitions are in the reference section; the important idea is that authority is determined from real capability, not marketing language.

6. What could happen if it is wrong?

Consequence asks what a credible failure, misuse, compromise or unavailable system could do to service continuity, health and safety, rights, privacy, customers, workers, finances or connected sectors. This is deliberately independent of authority. A low-authority assistant can still influence a high-consequence human decision, while a highly automated tool can be tightly bounded to a low-consequence function. CI-AIGAF records consequence as C1-C4.

7. How strong must the evidence be?

A system with greater authority, greater consequence, weak fallback, vulnerable affected groups, opaque supplier evidence or high uncertainty needs stronger assurance. The Assurance Class tells the organization how deep, realistic, independent and fresh the evidence must be. It is a framework decision, not an EU AI Act category.

8. Is permission to operate justified now?

The previous four answers do not themselves authorize production. Permission is granted through lifecycle gates, the applicable practices, evidence sufficiency and a bounded authorization envelope. The organization must be able to say what the AI is allowed to do now, for this version and context, and what would cause that permission to expire, narrow, suspend or reopen.

9. The four classifications must not be collapsed into one risk label

A frequent governance error is to treat one label — for example “high-risk” — as if it answered every question. CI-AIGAF EU-TEL deliberately separates legal status, operational authority, consequence and assurance. The same deployment can have a legal status that remains stable while its operational authority changes; or it can have unchanged authority while consequence rises because the service context changes.

Part III — Follow one AI Network Change Agent from idea to retirement

This part teaches the lifecycle as a story. The purpose is not to suggest that every organization must implement the exact example. It shows how the framework thinks when real facts change.

10. G0 — The idea arrives

A network automation team proposes an AI Network Change Agent because engineers spend too much time correlating alarms, checking historical changes and drafting low-risk configuration updates. At G0 the organization does not ask “Which model should we buy?” It asks whether the service need is legitimate, whether AI is necessary, what outcomes must be protected, who is accountable and what the system must never be allowed to do.

11. G1 — Define the thing being governed

The organization creates a canonical deployment boundary. The record includes the model and version; prompts and policies; RAG sources; historical change data; tool and API connections; NMS/EMS interfaces; service domains; machine identities; supplier components; users; countries; affected services; and the actions that can be proposed, submitted or executed.

12. G2 — Translate goals and obligations into testable requirements

The service team, engineering, security, legal/privacy and assurance functions now state what must be true before production authority can be considered. Requirements might include a maximum permitted change magnitude, excluded emergency-service objects, rollback latency, logging fields, approval rules, data limitations, supplier change notice, scenario coverage, evidence freshness and a maximum human intervention time.

13. G3 — Build or buy with evidence in mind

The procurement and engineering decision is tested against the requirements. The team asks whether the supplier will provide version information, known limitations, change notices, test artefacts, incident cooperation and exit support; whether APIs can enforce the intended authority; whether logs can reconstruct actions; and whether the system can be restricted if authorization changes.

14. G4 — Ask what has actually been demonstrated

Testing is performed in representative environments. The team does not merely collect test reports; it builds an assurance argument. What claim does each test support? Which version and topology were used? What scenarios were not covered? How independent was the challenge? What failure modes were observed? What does the evidence not justify?

15. G5 — Grant a bounded authorization, not a generic approval

The authorization authority decides what the system may do. The decision might permit the agent to generate and submit specified change types, in named clusters, during maintenance windows, with engineer approval, while prohibiting direct execution and excluding emergency-service objects. The authorization has an expiry date and explicit reopening triggers.

16. G6 — Check whether production can enforce the decision

A valid authorization can still fail operational readiness. G6 confirms that the correct model and configuration are deployed; IAM/PAM permissions match the envelope; monitoring works; rollback is available; named humans are trained and available; incident procedures are ready; and the system cannot bypass the approval path.

17. G7 — Treat continued operation as an active decision

The agent begins production use. Continued authorization depends on evidence remaining valid. The organization watches performance, drift, anomaly rates, overrides, change outcomes, supplier releases, data/RAG changes, privileges, service conditions, complaints and audit findings.

18. G8 — Incident and recovery authority

A proposed change is approved and causes instability because the agent did not account for a dependency introduced by a recent network change. The first actions are operational: contain the service impact, restrict the AI, preserve the pre-incident state and relevant evidence, open potentially applicable incident routes, and assign owners.

19. G9 — Reauthorize, materially change or close

Investigation finds that the new supplier model, new network dependency and insufficiently representative tests together invalidated part of the earlier assurance case. The organization updates the boundary and requirements, retests affected claims and decides whether to issue a new authorization envelope.

20. What the running case teaches

• The model is only one component of the governed system.
• Authority can change without a model change, especially when tools, credentials or workflow integration change.
• Legal status and operational classification are separate decisions.
• Evidence supports claims only within the conditions that make it relevant.
• Human oversight must be feasible in time and supported by real authority to intervene.
• Authorization is bounded and temporary; it can be reduced, suspended or reopened.
• An incident is both an operational event and an evidence-preservation event.
• Recovery is not equivalent to reauthorization.

Part IV — What each team contributes

CI-AIGAF EU-TEL is not owned by a single governance function. A central team can steward the method, but the evidence and decisions come from the people who understand the service, the network, the AI system, the law, the data, the security controls and the assurance process. The framework therefore separates contribution from decision right. A team can produce evidence without being allowed to approve its own evidence.

21. Operational Head / Service Owner

Own the service objective and acceptable operating boundary. Make sure the AI use case has a legitimate purpose, protected service outcomes, an accountable owner, defined failure constraints and a clear decision path when authority must be reduced. You should be able to see which AI systems are operating, their exact version, authority, authorization expiry, blocking conditions, open incidents and evidence exceptions.

22. Network Engineering / NOC / SOC

Define the real-world constraints: topology, protected objects, change limits, safe state, rollback, maintenance windows, alarm and monitoring coverage, service dependencies and emergency procedures. Validate AI-generated operational logic before it becomes production action.

23. AI / ML / Platform Engineering

Maintain versioned system boundaries, training/evaluation records, model and prompt/RAG configuration, known limitations, test evidence, monitoring and change information. Design the system so its tools and identities can be restricted when authority changes.

24. Cybersecurity / IAM / PAM

Bind machine identity, privileged access and tool permissions to the authorization envelope. Monitor credential and privilege changes. Make suspension real by removing capability, not merely changing a dashboard label.

25. Legal / Compliance / DPO

Apply the law to the actual deployment facts, roles, affected people and country. Record applicability reasoning, dates, notices, rights, data restrictions, retention constraints and reporting routes. Distinguish statutory requirements from framework controls and recommendations.

26. Independent Assurance / Internal Audit

Test whether controls are well designed and whether they actually operate. Challenge the evidence chain, sampling, realism, independence and residual uncertainty. Preserve findings and dissent. Verify corrective action independently where required.

27. Executive / Management Body

Understand the operating exposure, legal role, significant incidents, audit findings, unresolved exceptions and regulatory commitments. Ensure accountability, training, challenge and resources exist.

28. Procurement / Supplier Management

Obtain sufficient evidence, cooperation, change notification, security information, incident support, audit rights, concentration visibility and exit provisions for the intended authority.

29. Role-based reading map

Part V — Operating under the European legal environment

30. Law is an input to authorization, not a substitute for operational judgment

CI-AIGAF EU-TEL uses the EU AI Act as a central legal layer, but a telecom AI deployment can also engage cyber, communications, data-protection, resilience, accessibility, consumer, employment and product rules. The framework does not merge these regimes into one fictional “AI compliance” obligation. It keeps each legal source identifiable and turns applicable obligations into controlled requirements, evidence and decision points.

31. EU AI Act timing baseline used by this handbook

The handbook uses Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. Regulation (EU) 2026/1744 was published on 24 July 2026 and changed the staged application of the high-risk provisions. As of this handbook’s verification date, Chapter III Sections 1-3 apply from 2 December 2027 for AI systems classified as high-risk pursuant to Article 6(2) and Annex III, and from 2 August 2028 for AI systems classified as high-risk pursuant to Article 6(1) and Annex I, subject to the detailed transitional provisions and exceptions in the Regulation.

32. Telecom criticality does not automatically create an Annex III high-risk finding

Annex III point 2 concerns AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, or specified utility supply. The classification therefore turns on the actual intended use and the safety-component test, not on the fact that a telecom organization is important or regulated. CI-AIGAF EU-TEL separately applies operational authority, consequence and assurance classification so that a legally non-high-risk system can still receive stringent operational controls where the deployment can affect essential services.

33. Core legal overlays used by EU-TEL

34. Incident clocks should be opened in parallel, not sequentially

When an operational event could engage more than one regime, the initial response should contain the system and preserve evidence while the organization opens every potentially applicable route. NIS2 Article 23 uses a 24-hour early warning and 72-hour incident notification for significant incidents, followed by a final report normally within one month after the incident notification. The AI Act serious-incident route has different triggers and deadlines for high-risk AI systems. Privacy and national telecom rules can add further routes. CI-AIGAF EU-TEL therefore gives each potentially applicable clock a named owner rather than waiting for one team to decide which regime “owns” the incident.

Part VI — Evidence, human judgment and bounded authority

35. Evidence is a decision resource, not a document collection

Evidence answers a specific question for a specific system version and deployment context. A generic supplier white paper may help explain a technology, but it rarely proves that the deployed system will behave acceptably in a particular network state. A successful digital-twin test can be strong evidence for the scenarios actually represented; it is not proof for all topologies, traffic conditions or failure modes. CI-AIGAF EU-TEL therefore links every important claim to evidence, conditions, limitations, provenance and freshness.

The framework also preserves counterevidence and dissent. If a reviewer believes a test environment was unrepresentative, that concern belongs in the assurance record. A decision maker can still accept residual risk, but the record should not erase the uncertainty that was known when authority was granted.

36. Human oversight is a timing, comprehension and authority problem

The phrase “human in the loop” is useful only when the human can actually perform the intended control. The person must receive the relevant information, understand the proposal and its limitations, have time to decide, possess the authority and technical means to intervene, and be able to stop or reverse the action before the harm becomes unavoidable. CI-AIGAF EU-TEL therefore treats human oversight as something that must be demonstrated rather than declared.

37. Authorization should be enforceable

The framework’s most important operational construct is the authorization envelope. A decision such as “approved for production” is too broad. The authorization should specify the version, purpose, geography, network objects, tools, actions, thresholds, time windows, human approvals, rollback, monitoring, evidence, expiry and automatic suspension conditions that together define permission to operate.

Where technically feasible, the envelope should be reflected in IAM/PAM, API gateways, change controls, orchestration and network controllers. If the authorization expires or a critical blocking condition occurs, the system should be capable of losing credentials, tools or execution rights. Governance becomes credible when a decision can change the production state.

Part VII — Change, incidents, recovery and the loss of authority

38. A material change is any change that can invalidate a decision basis

A new model version is an obvious change, but it is not the only one that matters. A new tool, expanded credential, changed RAG corpus, new data source, different network topology, new intended purpose, supplier update, country expansion, revised threshold, unavailable human overseer or changed legal assumption can invalidate evidence or classification. CI-AIGAF EU-TEL therefore screens changes for their effect on authority, consequence, assurance, role, legal status and evidence validity.

39. Incident response should preserve the decision state

After an incident, teams often focus on service restoration — correctly. The governance challenge is to restore service without destroying the ability to reconstruct what happened. Relevant model/configuration versions, prompts, retrieved sources, inputs, outputs, tool calls, identities, human decisions, network state, logs, authorization envelope and associated change/incident identifiers should be preserved according to the applicable evidence and privacy rules.

The framework does not recommend copying all telecom data into one central governance store. A federated evidence model can retain stable references and integrity metadata while preserving material snapshots where necessary. Sensitive payloads can remain separately controlled. The objective is reconstructability, not indiscriminate retention.

40. Recovery and reauthorization are different

A network can be technically stable while the AI system remains unauthorized. G8 supports staged recovery: suspended, advisory-only, bounded execution and then potentially restored authority. If the incident or change affects the original decision basis materially, G9 triggers reauthorization. The organization should be able to explain why each step of authority was restored and what evidence supported it.

Part VIII — Making the framework usable across an organization

41. Adoption is not the same as authorization

An organization can be mature at AI governance and still have an individual system that should not operate. Conversely, a specific low-authority system can be well controlled while the wider organization remains immature. CI-AIGAF EU-TEL therefore separates enterprise adoption maturity from individual system authorization. AD0-AD5 describes how reliably the organization can perform the framework; it does not grant permission to any system.

42. Start with a small controlled portfolio, not every AI idea at once

The most effective implementation begins with a small number of deployments that represent different kinds of authority and consequence. For example: a NOC knowledge assistant, an AI-generated configuration tool, a closed-loop optimizer and a customer/workforce decision system. These reveal different requirements and help the organization build reusable registers, evidence practices, legal source controls, authorization mechanisms and training before scaling.

43. Give managers a way to pass the framework to their teams

A framework spreads successfully when the first reader can explain it without carrying a 150-page document into every meeting. Each team briefing should use the same four messages: what the framework protects, what changes for the team, what evidence the team must produce or consume, and which decisions the team is not allowed to approve by itself.

44. How to know the framework is becoming real

• Teams can name the actual AI systems and deployments operating in production, not just vendor products.
• Operations can show what each AI identity and tool is permitted to do and how authority can be revoked.
• Every material authorization can be traced to current evidence and an accountable decision.
• Supplier/model/tool changes trigger controlled screening rather than informal acceptance.
• Human oversight is tested for competence, timing and intervention capability.
• Incidents preserve evidence and start potentially applicable clocks without waiting for ownership arguments.
• Audit findings cannot be self-closed by the control owner where independent verification is required.
• Member State legal routes and authorities are controlled as country-specific metadata.
• Teams can explain the framework in plain language before they use the codes.

45. Reader checkpoint before the detailed reference

If the first eight parts have worked, the reader should now be able to explain CI-AIGAF EU-TEL without opening a reference table. The framework governs the authority of a deployed AI system. It separates legal status from operational authority and consequence. It asks for evidence proportionate to the uncertainty and impact. It moves the system through lifecycle gates. It grants a bounded permission to operate. It watches for changes that invalidate the decision basis. It preserves evidence during incidents. And it allows authority to decrease when confidence decreases.

The next part is intentionally more manual-like. It is a reference library for teams implementing the framework. It should be used after the operating model is understood, not as the first introduction.

Part IX — Detailed Practitioner Reference

This reference section retains the detailed framework material required by practitioners: lifecycle gates, P1-P18 practices, evidence and authorization mechanics, the 40 instruments, use-case playbooks, runtime operations, adoption and the Operational Assurance Control Plane. The wording below is intentionally more structured because its purpose is execution and auditability rather than first-time teaching.

• Reference A — Lifecycle gates G0-G9, explained gate by gate
• Reference B — The eighteen practices P1-P18, explained practice by practice
• Reference C — Evidence, assurance cases, human oversight and the authorization envelope
• Reference D — The 40 implementation instruments and how they fit together
• Reference E — Telecom use-case playbooks and classification patterns
• Reference F — Runtime operations, material change, incidents, recovery and reauthorization
• Reference G — Enterprise adoption, Member State localization and cross-border operation
• Reference H — Digital implementation: the Operational Assurance Control Plane
• Reference I — First implementation: a ten-step practitioner method and worked example
• Appendices — Traceability, glossary, legal source register and publication controls

Reference A — Lifecycle gates G0-G9: the decision path

This is the operational spine of CI-AIGAF EU-TEL. A gate is not a meeting, a sign-off email or a checklist. A gate is a decision that the available evidence is sufficient for the next level of commitment or authority. If the evidence basis later changes, the gate can reopen.

G0 — Use-case legitimacy

Frame the need before committing to AI.

The purpose of G0 is to stop the organization from treating “use AI” as the objective. The team first describes the service problem, affected people and minimum service that must be protected. It also considers whether a non-AI approach can meet the need with less uncertainty or operational coupling.

What the team is deciding

At this point the system should not need production authority. If the team cannot articulate a legitimate service need, accountable sponsor, affected parties and prohibited outcomes, the use case should not progress.

What must be true before the gate closes

What happens if the answer is “not yet”

Do not commit to AI or procurement; refine the service need, choose a non-AI alternative, or stop.

G1 — Classification and ownership

Define exactly what is being governed and who is accountable.

G1 creates the canonical system boundary. This is where the organization stops speaking about a product name and records the actual deployment: model, prompt/RAG, tools, identities, interfaces, suppliers, users, countries, intended purpose and executable actions. It also assigns the initial legal and operational classifications.

What the team is deciding

If the boundary is ambiguous, the wrong thing will be tested and the wrong evidence may be accepted. Shadow agents, inherited credentials and embedded automation are common reasons to hold the gate open.

What must be true before the gate closes

What happens if the answer is “not yet”

Keep the system unowned/unclassified and therefore unauthorized; restrict experimentation until the boundary and accountability are stable.

G2 — Requirements approval

Translate law, mission and risk into testable requirements before build/acquisition proceeds.

G2 is where broad obligations become engineering and operational requirements. “Be robust” is not enough. The team defines measurable service outcomes, failure constraints, human oversight requirements, safe state, rollback, logging, evidence acceptance criteria and the maximum authority the design may seek.

What the team is deciding

A weak G2 creates expensive problems later because teams procure technology before deciding what evidence, access and operational controls they will need. Requirements that cannot be tested should not support authorization.

What must be true before the gate closes

What happens if the answer is “not yet”

Return requirements to design/legal/operations; do not allow procurement or build to silently set the requirements after the fact.

G3 — Build/acquisition readiness

Confirm that control, evidence, continuity and exit can actually be obtained.

G3 tests the operating relationship with suppliers, platforms and internal architecture. A technically capable model can still be unsuitable if the organization cannot get system-level logs, change notice, evidence, incident cooperation, revocation control or a workable fallback.

What the team is deciding

This gate is where procurement, architecture, security and operations become part of AI assurance. Certification or vendor reputation does not replace deployment-specific evidence access.

What must be true before the gate closes

What happens if the answer is “not yet”

Renegotiate supplier/architecture controls, introduce compensating controls, lower authority, or reject the dependency.

G4 — Evidence sufficiency

Decide whether realistic evidence supports the proposed authority.

G4 is the assurance gate. The question is not whether testing was performed; it is whether the testing was representative enough to support the claims that matter. Reviewers examine realism, failure modes, degraded conditions, human intervention, rollback, rights impacts, limitations and independent challenge.

What the team is deciding

Evidence should be tied to the exact version and environment. Generic vendor benchmarks, happy-path demonstrations and stale test results are not enough for high authority.

What must be true before the gate closes

What happens if the answer is “not yet”

Require stronger testing/evidence, reduce the proposed authority, add conditions, or reject authorization.

G5 — Formal authorization

Make the permission-to-operate decision.

G5 converts the assurance case into a formal authorization. The approver is not deciding whether the technology is “good.” The decision is whether this exact deployment may operate with a defined authority envelope for a defined period and context.

What the team is deciding

Conditions, expiry, evidence limits, residual risk, waivers and stop triggers are part of the authorization. A red blocking condition cannot be neutralized by an overall green score.

What must be true before the gate closes

What happens if the answer is “not yet”

Do not release authority. The system remains restricted, pilot-only, advisory-only, deferred or rejected.

G6 — Operational readiness

Verify that the authorized design can actually be operated in production.

G6 separates design approval from production readiness. The organization confirms that production credentials, monitoring, trained people, runbooks, rollback, alerts, incident routes and exact deployed versions match what was authorized.

What the team is deciding

A system can pass validation and still fail G6 if production IAM is broader than the test environment, the alternate overseer is unavailable or the deployed build differs from the signed evidence.

What must be true before the gate closes

What happens if the answer is “not yet”

Delay production or reduce production authority until people, credentials, monitoring, rollback and versions match the envelope.

G7 — Continued operation

Continuously test whether the authorization basis remains true.

G7 is not passive monitoring. It continuously asks whether the facts that justified authorization remain true. Evidence freshness, performance, drift, complaints, supplier changes, privilege changes, legal changes, incidents and operational limitations can all reduce authority or reopen earlier gates.

What the team is deciding

The outcome is a decision: continue, continue with conditions, reduce authority, suspend, or reopen G8/G9. Monitoring without decision consequences is not assurance.

What must be true before the gate closes

What happens if the answer is “not yet”

Continue only with explicit conditions or reduce/suspend authority; open G8 for incident recovery or G9 for reauthorization when required.

G8 — Recovery / recommissioning

Control authority during incident, containment and staged restoration.

G8 exists because recovery creates pressure to restore service quickly. The framework therefore separates emergency containment authority from normal production authorization. Evidence is preserved, legal clocks are opened, safe state is established, root cause and corrective action are tracked, and restoration occurs in stages.

What the team is deciding

Recommissioning should not mean “the alarm cleared.” The organization must show that the causal condition is understood enough, controls are restored and the proposed authority is justified for the recovery stage.

What must be true before the gate closes

What happens if the answer is “not yet”

Keep the system suspended or at reduced authority until staged recommissioning evidence supports restoration.

G9 — Reauthorization or closure

Decide what happens after material change, expiry, replacement or retirement.

G9 prevents an old authorization from living forever. Material change, provider-role change, expiry, major redesign, relocation or retirement requires a formal decision about the future state. If the system continues, a new envelope supersedes the old one. If it retires, credentials, data, evidence and retention duties are closed deliberately.

What the team is deciding

The key test is whether old evidence still supports the changed system. If not, affected gates must reopen and evidence must be regenerated rather than inherited by assumption.

What must be true before the gate closes

What happens if the answer is “not yet”

Reauthorize with a new envelope, change authority, replace, retire or close; never let the old authorization silently persist.

Reference B — The eighteen practices P1-P18: what each practice actually does

The practices are the work of the framework. They are not eighteen sequential phases. Several practices operate at the same gate, and the same practice can reopen later. For a first-time reader, the simplest way to understand a practice is to ask: what problem does it prevent, what work does the team actually perform, what evidence should exist, and where does it affect authorization?

P1 — Establish Requirements for Success

Domain I — Define the service need, deployed boundary, intended purpose, legal and operational classifications, testable success conditions, authority ceiling and evidence plan before build or acquisition.

Why this practice exists

Without P1, teams can procure a capable AI system before knowing what it must prove or what authority it is allowed to seek.

What the practitioner actually does

• Define the service objective, affected parties and minimum service to protect.
• Draw the deployed system boundary, including tools, identities, suppliers and network interfaces.
• Assign AIA status, operator role, A0-A4 authority, C1-C4 consequence and Assurance Class.
• Translate legal/mission needs into testable acceptance criteria.
• Define the maximum authority and evidence plan before build/acquisition.

When it applies, what it produces and the telecom example

How this practice affects authorization

P1 sets the ceiling: later gates should not grant authority beyond the intended purpose, requirements and evidence plan defined here.

P2 — Robustness, Resilience and Service Quality

Domain II — Connect AI/system performance to telecom service outcomes, realistic failure/degradation scenarios, thresholds, monitoring and recovery.

Why this practice exists

Average model accuracy can look acceptable while essential-service or protected traffic degrades.

What the practitioner actually does

• Identify telecom service outcomes and protected traffic/service classes.
• Model normal, degraded and failure conditions, including dependencies.
• Test representative load, topology, geography and failure scenarios.
• Set thresholds that trigger intervention, restriction or suspension.
• Exercise rollback, fallback and recovery.

When it applies, what it produces and the telecom example

How this practice affects authorization

P2 can reduce or suspend authority when service/resilience evidence is weak or runtime thresholds are breached.

P3 — Automated and Agentic Behaviour

Domain II — Map agents, tools, plans, memory and action paths; define enforceable allow/deny rules; require verification and containment; govern agent change.

Why this practice exists

An agent can accumulate effective authority through tool chaining even when no single prompt says it is autonomous.

What the practitioner actually does

• Map every agent, tool, API, memory store and action path.
• Specify what may be proposed, submitted, executed, chained or delegated.
• Use independent preconditions/verifiers for consequential actions.
• Test containment, credential revocation and tool disablement.
• Re-screen changes to planning, memory, tools, permissions or multi-agent coordination.

When it applies, what it produces and the telecom example

How this practice affects authorization

P3 determines the enforceable action boundary and is central to whether the system is A1, A2, A3 or A4.

P4 — Emergency Override, Recovery and Situation Awareness

Domain II — Design credible human command, independent telemetry, intervention-time budgets, stop/override/fallback and recovery authority.

Why this practice exists

A “human in the loop” can be nominal if the person cannot understand or intervene before the action is irreversible.

What the practitioner actually does

• Define who has command authority and what independent telemetry they see.
• Measure detection, comprehension, decision and intervention time.
• Test stop, override, rollback and safe-state actions.
• Provide alternate coverage and incident authority.
• Redesign authority when intervention cannot occur before irreversibility.

When it applies, what it produces and the telecom example

How this practice affects authorization

P4 limits authority when human command is not credible or independent recovery cannot be demonstrated.

P5 — Identity and Access Management for AI Agents

Domain III — Give each AI/agent action an attributable identity, least privilege, scoped credentials, session attribution and independent revocation.

Why this practice exists

Shared human accounts and standing privileges make accountability and suspension unreliable.

What the practitioner actually does

• Create a unique machine/service identity for each consequential execution path.
• Bind credentials to deployment/version and least privilege.
• Prevent shared or borrowed human privileged accounts.
• Log sessions/actions with attributable identity.
• Test rapid independent revocation and expiry.

When it applies, what it produces and the telecom example

How this practice affects authorization

P5 turns authorization into actual technical privilege; loss of identity control can invalidate the envelope.

P6 — External AI Supply Chain and Third-Party Risk

Domain III — Control supplier evidence, change notice, incident cooperation, continuity, exit, nth-party and concentration risk.

Why this practice exists

A reputable supplier can still make high authority unjustifiable if the deployer cannot access necessary evidence or control changes.

What the practitioner actually does

• Tier suppliers and critical nth parties by dependency and authority.
• Require evidence access, logs, change notice and incident cooperation.
• Assess concentration, substitutability, continuity and exit.
• Record supplier-controlled uncertainty.
• Lower authority when evidence/control cannot support the requested class.

When it applies, what it produces and the telecom example

How this practice affects authorization

P6 can cap authority when supplier evidence, change control, incident cooperation or exit is inadequate.

P7 — Internal AI Supply Chain, Data and Provenance

Domain III — Control model, data, prompt, RAG, configuration and pipeline lineage so evidence remains tied to what is actually running.

Why this practice exists

A deployment can materially change without changing the base model version.

What the practitioner actually does

• Maintain lineage for model, prompt, RAG, data, policy and configuration.
• Use controlled repositories/pipelines and approved versions.
• Preserve provenance and integrity metadata.
• Detect internal changes that invalidate evidence.
• Tie evidence and authorization to exact component versions.

When it applies, what it produces and the telecom example

How this practice affects authorization

P7 preserves the link between evidence and the running configuration; uncontrolled change can force reauthorization.

P8 — AI-Aware Incident Analysis and Response

Domain IV — Detect AI-specific failure patterns, preserve evidence, open multiple legal routes, contain authority, investigate and control recommissioning.

Why this practice exists

Incidents are mishandled when teams wait to decide whether the problem is “AI,” cyber, privacy or telecom before preserving evidence and opening clocks.

What the practitioner actually does

• Recognize AI-specific and combined failure signals.
• Freeze relevant evidence and preserve pre-incident state.
• Open all potentially applicable legal/reporting routes.
• Contain or reduce operational authority.
• Connect root cause and corrective action to staged recommissioning.

When it applies, what it produces and the telecom example

How this practice affects authorization

P8 can immediately reduce/suspend authority and governs the evidence needed to move through G8 recovery.

P9 — Calibrated AI Risk Training and Workforce Readiness

Domain IV — Demonstrate system-specific competence, limitations knowledge, intervention ability, shift coverage and refresher readiness.

Why this practice exists

Training completion is not evidence that an operator can respond correctly under realistic pressure.

What the practitioner actually does

• Define role-specific competence for operators, approvers and responders.
• Teach system-specific limitations, not generic AI awareness only.
• Use scenario qualification under realistic failure/uncertainty.
• Verify actual IAM authority to intervene.
• Maintain shift coverage, alternates and refresher evidence.

When it applies, what it produces and the telecom example

How this practice affects authorization

P9 determines whether named humans can perform the oversight and response responsibilities assumed by the authorization.

P10 — Multi-Tiered AI Logging and Audit

Domain IV — Make consequential AI actions reconstructable and preserve integrity, retention and independent audit evidence.

Why this practice exists

A bad outcome cannot be governed if nobody can reconstruct which version, prompt, tool, approval and network action produced it.

What the practitioner actually does

• Define event schemas for decisions, tool calls, approvals and executed actions.
• Preserve integrity, timestamps, versions and evidence references.
• Set record-specific retention rather than “keep everything.”
• Make consequential actions reconstructable end-to-end.
• Use independent audit and effectiveness testing for critical controls.

When it applies, what it produces and the telecom example

How this practice affects authorization

P10 provides the reconstruction and auditability needed to sustain, challenge or revoke authorization.

P11 — AI-Aware Mission Continuity and Disaster Recovery

Domain IV — Maintain essential service when AI, cloud, supplier, identity, data or automation fails; test fallback and recovery sequencing.

Why this practice exists

AI can become a single point of failure when no workable non-AI or reduced-authority mode exists.

What the practitioner actually does

• Identify critical dependencies and acceptable degraded modes.
• Define non-AI/manual/reduced-authority fallback.
• Set recovery objectives and sequencing.
• Exercise dependency failure, failover and recommissioning.
• Ensure the AI itself is not required to recover from its own failure.

When it applies, what it produces and the telecom example

How this practice affects authorization

P11 limits authority where fallback and continuity are not credible for the consequence tier.

P12 — Validate AI-Generated Operational Logic and Artifacts

Domain V — Treat generated configuration, code, scripts, policies, runbooks and incident analysis as controlled artifacts requiring semantic validation.

Why this practice exists

Syntactically valid AI-generated configuration can still be topologically or operationally unsafe.

What the practitioner actually does

• Identify AI-generated operational artifacts that can affect production.
• Apply deterministic/syntactic checks where useful but do not stop there.
• Perform semantic/service-effect validation and peer/independent review.
• Control repository, approval, rollback and provenance.
• Prevent execution of artifacts that have not passed required validation.

When it applies, what it produces and the telecom example

How this practice affects authorization

P12 blocks production use of AI-generated logic/artifacts until the required validation is complete.

P13 — Integrated AI Assurance Case and Risk Acceptance

Domain I — Assemble claims, evidence, limitations, dissent, independent review and residual risk into the formal authorization case.

Why this practice exists

Scattered documents and vendor reputation do not prove that the current deployed configuration deserves the requested authority.

What the practitioner actually does

• State the claims that must be true for the requested authority.
• Link each material claim to current evidence and known limitations.
• Require independent challenge appropriate to Assurance Class.
• Record dissent, residual uncertainty and decision authority.
• Set validity, expiry and reopening triggers.

When it applies, what it produces and the telecom example

How this practice affects authorization

P13 is the formal claim-evidence-decision structure used at G5 and again for continued operation/change.

P14 — Explainability, Interpretability and Operational Decision Transparency

Domain V — Define and test explanations for operators, approvers, affected persons, auditors, incident teams and authorities.

Why this practice exists

An explanation can be fluent yet useless for an operator or fabricated after the fact.

What the practitioner actually does

• Define which audiences need explanations and what decisions they must make.
• Test explanation fidelity and usefulness, not fluency only.
• Preserve inputs, outputs and action context for incident reconstruction.
• Avoid fabricated post-hoc rationale.
• Balance transparency with network/security confidentiality.

When it applies, what it produces and the telecom example

How this practice affects authorization

P14 supports safe operator action, contestability and incident reconstruction; poor explanations may require lower authority or stronger controls.

P15 — AI Privacy, Sensitive Inference and Purpose Limitation

Domain V — Control personal/communications/location data, derived inference, purpose, lawful basis, retention, access and special-category workflows.

Why this practice exists

Data gathered for network operations can silently become profiling, model memory or sensitive inference.

What the practitioner actually does

• Inventory personal, traffic, location, communications and inferred data.
• Record purpose, lawful basis, minimization and retention decisions.
• Control memory, reuse, inference and access.
• Run DPIA/special-category workflows where required.
• Delete or restrict data when the authorized purpose ends.

When it applies, what it produces and the telecom example

How this practice affects authorization

P15 can restrict data use, memory, inference, retention and therefore the authorized operating envelope.

P16 — Fair, Accessible and Equitable Essential Services

Domain VI — Define equitable service and accessibility outcomes, test distributional effects, investigate disparities and govern trade-offs.

Why this practice exists

Fleet-wide KPI improvement can hide consistent harm to rural, vulnerable or accessibility-dependent users.

What the practitioner actually does

• Define protected service/access outcomes before optimization.
• Select relevant groups/geographies/service classes for distributional testing.
• Monitor disparities, not only aggregate KPI.
• Investigate and remediate adverse patterns.
• Document justified trade-offs and exceptions.

When it applies, what it produces and the telecom example

How this practice affects authorization

P16 can impose service protections, thresholds or remediation conditions even when aggregate performance is strong.

P17 — Stakeholder Engagement, Contestability, Notification and Redress

Domain VI — Identify affected stakeholders, provide notices and effective human review, correction, complaint and remedy paths.

Why this practice exists

People can be trapped in automated processes with no meaningful route to challenge a consequential outcome.

What the practitioner actually does

• Map affected customers, workers, communities and representation gaps.
• Provide understandable notices where required.
• Create effective complaint, human review, correction and remedy routes.
• Track outcomes and recurring adverse patterns.
• Preserve accountability for the final decision.

When it applies, what it produces and the telecom example

How this practice affects authorization

P17 creates the notice, review and remedy conditions needed for accountable operation where people are affected.

P18 — Cross-Sector Interdependencies and Cascading AI Risk

Domain VI — Map shared dependencies and concentration, test cross-sector/common-mode failure and coordinate recovery.

Why this practice exists

Each system can pass its local test while shared cloud, power, telecom or model dependencies create correlated failure.

What the practitioner actually does

• Map telecom dependencies on power, cloud, DNS, satellite, finance, emergency and other shared services.
• Identify shared models/platforms and concentration.
• Test common-mode and cascading scenarios.
• Coordinate cross-sector incident contacts and exercises.
• Sequence recovery so local optimization does not damage wider recovery.

When it applies, what it produces and the telecom example

How this practice affects authorization

P18 can increase Assurance Class, constrain scope or require coordinated recovery when systemic dependencies are material.

Reference C — Evidence, assurance cases, human oversight and the authorization envelope

The framework grants authority only to the extent that evidence can justify it. Evidence therefore needs a clear chain from requirement to control to test to claim to decision. The strongest part of the model is that authority can decrease when evidence becomes stale, contradicted or inapplicable.

16. Evidence is not the same as documentation

A policy can state what the organization intends. Evidence shows what happened, under what version and conditions, and with what limitations. For high-authority telecom AI, assurance depends on deployment-specific evidence rather than a collection of generic documents.

Evidence-quality questions

17. Federated evidence architecture

EU-TEL does not recommend copying all network telemetry and sensitive payloads into one governance repository. Source telemetry can remain in SIEM, OSS/BSS, MLOps, data and supplier systems. The assurance layer stores stable references, scope, provenance, hashes, manifests and protected snapshots for material authorization and incident evidence. This preserves reconstruction while limiting unnecessary duplication of sensitive data.

18. The Operational Authorization Envelope

The authorization envelope is the bridge between governance and production. It tells operations and technical controls what the system is allowed to do. A signed approval that does not change credentials, tool permissions or deployment controls is weaker than an enforceable envelope integrated with IAM/PAM, API gateways, change control, orchestration and network controllers.

19. Human oversight: when “human in the loop” is not enough

Human oversight must be operationally possible. Naming an engineer or requiring an approval is not enough when the system can act before the person can detect, understand, decide and intervene. EU-TEL therefore treats oversight as a timing and authority problem.

The timing model is a governance aid, not a claim that every operational decision can be reduced to a single precise number. Its purpose is to prevent nominal oversight from being credited when intervention is physically or cognitively impossible within the available time.

Reference D — The 40 implementation instruments: how records connect to decisions

Volume 5 contains forty controlled instruments. They are not forty independent forms. They are linked records around the same system/version, gate, owner, evidence and authorization. The easiest way to use the toolkit is to understand the seven instrument families first, then open only the records triggered by the deployment and gate.

20. The seven instrument families

21. All 40 instruments — readable reference

R-series — Controlled registers

F-series — Assessments and decisions

S-series — Supplier / supply-chain pack

C-series — Control and readiness pack

M-series — Monitoring and management pack

I-series — Incident and recovery pack

A-series — Authorization and assurance pack

22. Which instrument do I use first?

A first-time practitioner should not start by completing forty forms. Start with the event that brought the system into the framework, then follow the connected records.

Reference E — Telecom use-case playbooks: start from function, then classify the deployment

The use-case catalogue helps a team ask better questions; it does not assign an automatic legal or operational classification. The same vendor model can be a low-authority NOC assistant in one deployment and a high-authority network-control agent in another. Intended purpose, executable actions, affected service, data, safety function, geography and human control determine the result.

23. How to use the catalogue correctly

1. Choose the closest functional use-case pattern.
2. Define the exact deployment boundary and executable actions.
3. Apply the legal screen and operator-role analysis to that actual deployment.
4. Assign A0-A4 authority and C1-C4 consequence independently.
5. Select the Assurance Class and required evidence.
6. Record reclassification triggers so the starting point is not mistaken for a permanent decision.

24. Four walkthroughs for first-time readers

NOC knowledge / RAG assistant

The system retrieves network procedures and proposes answers to engineers but has no write access. Begin by confirming data sources, intended use, hallucination/unsupported-claim controls and whether recommendations can become consequential without further validation. Operationally this often starts at low authority, but the class can rise if engineers routinely treat its output as de facto instructions.

AI-generated network configuration

The system generates CLI/API/policy changes. If output is only drafted, P12 validation and P14 operator transparency are central. If it can submit or execute changes, P3/P5 authority and identity controls, P4 override, P10 logging, P13 assurance and A02 envelope become decisive.

Closed-loop RAN optimizer

The system continuously changes parameters to optimize service objectives. Classification must consider actual execution authority, protected service classes, human intervention feasibility, rollback and whether average KPI improvement masks adverse distributional effects.

Customer or workforce decision AI

The system influences people rather than network control. Operational authority may be lower than a network agent while legal, privacy, equality, transparency, notice, contestability and remedy requirements can be much stronger.

Reference F — Runtime operations, material change, incidents, recovery and reauthorization

Authorization is not the end of governance. In telecom, the most important question after deployment is whether the evidence and assumptions that justified authority remain true while network state, software, suppliers, traffic, people and law continue to change.

25. What the Operational Head should see every day

The operational view should show permission and exposure, not a generic compliance percentage. A system with a high score but an expired authorization, lost monitoring or critical evidence gap is not “green.”

• AI systems operating now, exact production version and deployment geography.
• Current A0-A4 authority, C-tier, Assurance Class and authorization state.
• EU legal status and operator role, including unresolved or time-dependent obligations.
• Authorization/evidence expiry, temporary waivers and compensating controls.
• Human-oversight coverage, alternate availability, qualification and intervention feasibility.
• Performance, drift, anomaly, service-quality, privacy/fairness/accessibility and resilience thresholds.
• Unreviewed supplier/model/configuration/data/prompt/RAG/tool changes.
• Open incidents with all potentially applicable legal/reporting clocks and named owners.
• Systems automatically restricted, suspended or degraded and the reason.
• Complaints, adverse outcomes, audit findings, CAPA and upcoming reauthorization/tests/drills.

26. Material change and reauthorization

Material change is broader than a new model version. A prompt policy, RAG corpus, tool permission, network scope, supplier, operating country, data source, intended purpose or legal assumption can invalidate the evidence on which authorization was based. The framework therefore treats change as an evidence and authority event.

1. Detect and record the change: model, prompt, RAG, tool, permission, data, purpose, topology, country, supplier, personnel, threshold, law or operating assumption.
2. Run F09 and update R07. Ask whether intended purpose changed, whether a substantial modification/provider-role shift occurred, and whether old evidence remains valid.
3. Re-run F02/F03/F04 if legal status, role, authority, consequence or assurance may change.
4. Reopen the gates whose decision basis is no longer valid; do not reopen everything blindly, but never skip an affected decision.
5. Retest affected claims under representative conditions.
6. Issue a new A01/A02 authorization if continuing; preserve the superseded authorization and evidence chain.

27. Multi-regime incident command

Telecom AI incidents can cross organizational and legal boundaries. The correct first move is not to argue about which regime “owns” the incident. Contain the system, preserve evidence, open the potentially applicable routes, assign an owner to each clock and then determine applicability with the appropriate legal and regulatory teams.

28. Recovery is a controlled authorization state

G8 recovery should support staged authority. A system can move from suspended to advisory-only, then to bounded execution, rather than jumping directly from incident to full production. I05 records the recommissioning decision, and a material change can route the system into G9 for full reauthorization.

Reference G — Enterprise adoption and Member State localization

CI-AIGAF EU-TEL governs individual systems and also provides a method for an organization to adopt the framework consistently across a portfolio. Maturity does not authorize systems; it describes how reliably the organization can perform the governance process.

29. AD0-AD5 adoption maturity

AD0-AD5 answers “how capable is the organization at applying EU-TEL?” It does not answer “may this A4 system operate?” An AD5 organization still has to pass the gates and produce the evidence for each deployment.

30. W01-W12 implementation workstreams

The workstreams are the enterprise build plan. They establish mandate, inventory, legal source control, practices, evidence, technology integrations, training, pilot validation and governance needed to make the framework repeatable.

31. AC01-AC12 adoption controls

The adoption controls are controlled records for enterprise implementation. They make the rollout itself auditable: who mandated the profile, which systems are in scope, which Member State sources were checked, what pilot evidence exists, what exceptions remain and which version of the profile is released.

32. Member State localization: one framework, twenty-seven controlled deltas

EU-level consistency is valuable, but telecom obligations and authorities are not identical across Member States. EU-TEL therefore keeps a common core and localizes only the elements that truly vary: transposition, competent authorities, telecom licences, reporting routes, labour consultation, privacy/ePrivacy enforcement, language and other national requirements.

• AC07 creates and maintains the national legal source and authority register.
• AC08 approves the localized Member State release for use.
• AC09 controls cross-border deployments and a strictest-condition matrix where one common technical configuration must satisfy several countries.
• Country annexes should carry source date, reviewer, status and next verification; a URL alone is not validation.

Member States covered by the Volume 6 annex structure

Reference H — Digital implementation: the Operational Assurance Control Plane

The application is the execution layer of the framework. It should make the framework easier to operate and harder to bypass. It is not another document repository and it should never allow AI to approve its own legal classification, evidence sufficiency or operational authorization.

33. What the application changes operationally

The application’s central object is the permission to operate for one identified AI system version, in one deployment context and geography, within a defined authorization envelope supported by current evidence. This is different from a conventional GRC dashboard because a decision is intended to affect production authority.

34. Controls discovered during application development

Building the control plane exposed several controls that should be explicit in the written profile rather than remaining software-only. These are treated as strengthening of existing practices and adoption governance, not as silently invented new practices.

Reference I — First implementation: ten steps for the Operational Head

A first-time practitioner does not need to memorize the whole framework before starting. The safest approach is to follow one deployment through the ten steps below while using the detailed volumes only when a specific decision, practice or record needs deeper treatment.

35. Ten-step practitioner method

36. Worked example: AI-generated network configuration with execution

37. How to know that the framework is working

The framework is working when governance decisions change operational reality. Missing evidence lowers or blocks authority. A material change reopens classification. A failed audit can invalidate the authorization basis. An incident freezes evidence and starts the applicable clocks. Recovery is staged. Retirement closes credentials and retention obligations. If the application only creates records while the AI retains the same production power regardless of those decisions, the control plane is not yet implementing the framework.

Appendix A — Framework traceability: from concept to application

Traceability prevents the Master Guide, detailed volumes, instruments, legal anchors and application from becoming separate systems. The examples below show the expected chain. The controlled v1.0 publication should maintain this mapping as the framework changes.

Appendix B — Glossary for first-time readers

The glossary intentionally defines terms in operational language. Legal terms should still be read with their statutory definitions where applicable.

Appendix C — Primary EU source register used by the current Guide

This register is a framework source-control aid. It is not a substitute for a deployment-specific legal review or the national source registers maintained under AC07.

Appendix D — Reconciliation findings and publication controls

This Reader-Clear edition preserves the Core architecture while making EU-TEL easier to learn. It also records where application development has clarified implementation expectations. Normative changes to the six-volume baseline should be controlled explicitly rather than being introduced only through explanatory prose.

Closing operating principle

No authority claim should exceed the realism of the evidence supporting it.

When evidence, law, configuration, suppliers, people or operating conditions change, authority must be capable of changing with them. This is the central discipline that turns CI-AIGAF EU-TEL from a collection of governance documents into an operational assurance framework.