01 / Activity diagram
The lifecycle and optional RAG/fine-tuning branches. Failed assurance returns to remediation; material change reopens affected gates. G0–G7 definitions below govern the transitions.
01 / Scope & design premise
Govern the whole system, from intent to retirement.
This generic reference architecture connects product governance, secure engineering, model development, retrieval-augmented generation (RAG), assurance and production operations. It supports predictive ML, externally supplied foundation models, fine-tuned models and combinations of these approaches. It is a research design for adaptation and empirical validation, not an assertion that an implementation has passed assurance.
RAG and fine-tuning are distinct, optional paths. RAG retrieves versioned external information at inference time; it ordinarily does not update model weights. Fine-tuning changes weights or adds learned adapters using training data. A system may use either, both or neither. Changes to a retrieval corpus, embedding model, index, system prompt, tool permission or gateway policy can alter behavior even when model weights remain unchanged.
The six UML views use activity actions and decisions, components and dependencies, execution nodes, sequence lifelines, states and transitions, and evidence classes. They are based on UML 2.5.1 [S1]. Domain labels such as governance gates are Institute modeling conventions. SVGs use authored UML notation; paired PlantUML files express the same conceptual views but are not a tool-exported XMI model.
02 / UML architecture atlas
Six views. One assurance lifecycle.
Select a view, or open a diagram at full size. Diagrams render locally as SVG without external scripts or a third-party rendering service.
02 / Component diagram
The model is one component of a wider system. Policy enforcement, ACL-aware retrieval, tool authorization, signed artifacts and security telemetry have separate responsibilities.
03 / Deployment diagram
Separate development, test, edge, production, data/model and security operations environments. Only approved artifacts cross the promotion boundary.
04 / Sequence diagram
A protected RAG request: authenticate, retrieve within user/tenant permissions, treat context as untrusted, validate outputs, enforce tool policy and emit minimized security events.
05 / State machine diagram
Authorization belongs to a specific release baseline. Incidents may quarantine it; remediation and material change require fresh assurance and a new recorded decision.
06 / Class diagram
An evidence model links products, release manifests, gate decisions, test artifacts, exceptions and monitoring plans. Cardinalities describe records, not automatic approval logic.
03 / Accountability & approval
Eight evidence-bearing checkpoints.
Gate identifiers are Institute research conventions. Approval requires an authorized reviewer’s recorded decision; a diagram transition alone is never authorization.
| Gate | Purpose | Accountable reviewers | Required evidence | Exit condition |
|---|---|---|---|---|
| G0 | Purpose & regulatory scope | Product owner + legal/compliance | Intended use, affected people, jurisdictions, provider/deployer/GPAI role, prohibited-practice screen, high-risk and transparency assessment, privacy impact screening. | Record applicable obligations and deadlines; stop prohibited uses. Determine whether FRIA, DPIA, conformity assessment, registration or sector duties apply. |
| G1 | Architecture & data readiness | Security architect + data steward + privacy | Trust boundaries, abuse cases, supplier diligence, data licensing/consent, classification, minimization, tenant isolation, approved training and retrieval data. | Approve threat model and selected controls; block unresolved rights/provenance defects. Document model-provider retention, training-use and regional-processing settings. |
| G2 | Candidate baseline | ML/RAG engineering + configuration manager | Reproducible build; code, model, adapter, dataset, corpus, index, embeddings, prompts, tool schema and policy versions; independent holdout and provenance. | Freeze a signed candidate manifest. RAG updates need retrieval evidence; weight changes need training and model evidence. Either or both paths may apply. |
| G3 | Independent assurance | QA + model validation + authorized security testers | Functional/regression tests, model performance and subgroup results, XAI limitations, RAG grounding/ACL tests, SAST/SCA/secrets/IaC scans, pen test and adversarial report; remediation retests. | Meet use-case thresholds set at G1. Block exploitable critical findings and unmitigated high risks; document any eligible time-bound exceptions. No exception can waive a mandatory legal duty. |
| G4 | Governance release decision | Accountable risk owner + release authority, informed by compliance/security/validation | Complete evidence pack, residual risk, independent challenge, human oversight, user transparency, incident plan, monitoring thresholds, rollback plan, applicable legal/conformity records. | Approve, reject or impose enforceable conditions against the exact manifest digest. Missing mandatory evidence blocks release. Deployment staff cannot self-approve their own assurance. |
| G5 | Operational acceptance | Service owner + SecOps + ModelOps | Canary/shadow outcomes, SIEM signal validation, synthetic alert test, rollback drill, on-call coverage, SLOs, resource limits, dependency and egress checks. | Promote only after operational acceptance. Fail the canary back to the last approved baseline; retain the failing release evidence. |
| G6 | Continuous assurance & change | Service owner + SecOps + ModelOps; architecture and risk review | Threat alerts, quality/safety/bias signals, drift, retrieval health, supplier changes, exceptions, vulnerability remediation, threat hunts and periodic adversarial testing. | Contain breaches; reassess scope and repeat affected gates for material changes. Review risk and oversight on a defined cadence; never silently promote retraining. |
| G7 | Retirement | Product/data owner + security + records management | Decommission plan, identity/key revocation, endpoint/index removal, vendor exit, required retention, dataset deletion and downstream impact review. | Confirm service closure and legal holds; retain required decision and assurance records in access-controlled storage. |
04 / Regulatory checkpoints
Applicability precedes the compliance claim.
The EU AI Act is risk- and role-dependent [S2–S3]. G0 records jurisdiction, intended purpose, provider/deployer status, general-purpose AI involvement, prohibited uses, high-risk classification and transparency duties. Fine-tuning or substantial modification can change the role analysis; assess rather than assume. Legal/compliance maintains the applicable law version, phased commencement dates and any sector-specific duties.
| Checkpoint | Evidence focus for applicable obligations |
|---|---|
| G0 / G1 | Classification and prohibited-practice screening; determine transparency, data protection and any fundamental-rights assessment obligations. |
| G1 / G2 | For applicable high-risk systems: risk management, data governance, technical documentation, logging, oversight, accuracy, robustness and cybersecurity (Articles 9–15). |
| G3 / G4 | Provider quality management, conformity/registration and deployer duties where applicable (including Articles 17, 43, 49 and 26); assess GPAI obligations separately (Chapter V). |
| G5 / G6 | Applicable post-market monitoring and serious-incident reporting (Articles 72–73); preserve evidence and route reporting decisions to legal/compliance. |
Article references are navigation aids, not an exhaustive applicability matrix. Exact deadlines must be checked against the current consolidated law and official implementation guidance at each release; this architecture intentionally avoids embedding a single universal commencement date. Human oversight must have defined authority, competence, intervention mechanisms and escalation routes.
05 / Security control architecture
ISO/IEC 27002:2022 as a control design reference.
ISO/IEC 27002 supplies guidance for selecting and implementing security controls [S4]. The mappings below are proposed research cross-references, not a full statement of applicability or a certification assertion. Verify final control names and implementation detail against the licensed standard; select controls through risk assessment. AI-specific validation and governance must supplement general security controls.
| Control concern | 27002 reference | Proposed implementation | Reviewable evidence |
|---|---|---|---|
| Governance and accountability | 5.2, 5.8, 5.31, 5.34 | Assign owners, integrate security into projects, track obligations and personal-data safeguards. | Risk/applicability register; owner roster; privacy review; G0/G4 records. |
| Supplier and AI service dependencies | 5.19–5.23 | Evaluate model/cloud suppliers, contractual data use, incident notice, sub-processors, model retirement and service changes. | Diligence record; contracts; service-change alerts and exit test. |
| Identity, secrets and cryptography | 5.15–5.18; 8.2–8.5; 8.24 | Scope user/workload identities; protect privileged access, signing keys and model API secrets; rotate and revoke credentials. | Access review; key inventory; denied cross-tenant and unauthorized tool tests. |
| Secure engineering | 8.25–8.29; 8.31–8.33 | Use secure lifecycle requirements, architecture review, secure code, independent acceptance tests, environment separation and controlled change. | Threat model; scan/test reports; signed manifest; release and rollback records. |
| Data and leakage protection | 5.12–5.14; 8.10–8.12 | Classify and protect training/retrieval data; mask where appropriate; prevent output/log leakage; delete according to retention rules. | Corpus lineage; ACL propagation tests; DLP probes; deletion verification. |
| Network and platform defense | 8.7–8.9; 8.20–8.22 | Harden workloads, patch vulnerabilities, manage configurations, enforce network boundaries and controlled egress. | Configuration evidence; exposure inventory; FW/WAF/gateway rule validation. |
| Telemetry and incident handling | 8.15–8.17; 5.24–5.28 | Log and monitor with synchronized time; triage, respond, learn and preserve evidence. | Alert test; time-sync check; response exercise; chain-of-custody record. |
| Resilience | 5.29–5.30; 8.13–8.14 | Protect information during disruption; maintain ICT readiness, backups and redundancy appropriate to criticality. | Restore/rollback results; dependency outage and recovery exercises. |
Control identifiers refer to ISO/IEC 27002:2022 clauses (the corresponding ISO/IEC 27001 Annex A identifiers use the A. prefix). This publication summarizes implementation ideas and does not reproduce the standard’s control text.
06 / Pre-release assurance
Model testing is broader than explainability.
The assurance plan uses risk-based testing and documented measurement limits, informed by NIST AI RMF and its Generative AI Profile [S5–S7]. Establish datasets, test ownership, tolerances and stopping criteria before seeing results. Keep training, tuning and final evaluation partitions separate; inspect data contamination and repeated-test overfitting.
| Test stream | Scope | Example acceptance evidence |
|---|---|---|
| Software QA | Unit, integration, regression, accessibility, performance, resilience, API contracts and user acceptance. | Error/latency budgets; regression acceptance; failover and restore evidence. |
| Predictive model validation | Leakage-free holdouts, calibration, uncertainty, robustness, distribution shifts and subgroup performance; domain-expert review. | Use-case-specific accuracy/precision/recall or other loss measures; confidence intervals, subgroup tolerances and error consequences. |
| GenAI / RAG evaluation | Task success, factuality, faithfulness, abstention, citation support, retrieval relevance and coverage; multilingual/edge cases; judge calibration. | Grounded-answer and unsupported-claim rates; retrieval precision/recall where meaningful; human-reviewed samples; denied unauthorized retrieval. |
| Explainability / XAI | SHAP/LIME where suitable, feature attribution stability, counterfactuals, interpretable baselines, user comprehension and decision traceability. | Faithfulness/stability checks and explanation usability. XAI is supporting evidence; it does not prove accuracy, fairness, causality or safety. Generated rationale is not verified internal reasoning. |
| Security penetration testing | Authorized application/API/cloud/identity tests, exposed services, authZ/tenant boundaries, secrets, egress and tool execution; retest fixes before release. | Reproducible findings with impact, scope, remediation and retest; tests explicitly cover WAF/AI-gateway bypass and downstream controls. |
| Adversarial AI / red teaming | Direct/indirect prompt injection, poisoned retrieval, tool abuse, data exfiltration, model extraction, jailbreaks, unsafe agency and resource exhaustion. | Threat-based test cases, control bypass outcomes and residual-risk decisions. Use synthetic sensitive data and approved rules of engagement. |
| Supply-chain and training assurance | Dataset/adaptor provenance, dependency scans, signed artifacts, training-job isolation, reproducibility, memorization/privacy tests and model-provider change checks. | Versioned bill of materials; data/model lineage; signature verification; approved training inputs and release artifact. |
Independent challenge: Engineering supplies evidence; QA/model validation and security assess it within their competence; the accountable business/risk authority records the release decision. Smaller organizations may combine roles, but must document conflicts and obtain appropriate independent review. Security and compliance concurrence do not transfer accountability away from the release authority.
07 / Post-release assurance
Operate the controls. Re-test the assumptions.
| Accountable function | Continuous or scheduled activity | Response and re-authorization |
|---|---|---|
| SecOps / SOC | Continuously ingest FW/WAF/AI-gateway, IAM, endpoint, cloud, application and tool-broker events. Correlate retrieval spikes, denied access, unusual token/cost usage, privilege changes, exfiltration indicators and compromised credentials. | Triage by impact and confidence; revoke sessions/keys, isolate tools/endpoints, preserve evidence and invoke incident response. Validate detections with synthetic events and threat hunts. |
| Security architecture operations | Review firewall/WAF/gateway policies, authentication paths, trust boundaries, private endpoints, tenant isolation, provider egress and configuration drift. Include rule tuning and exceptions. | Control failure or a new execution/data path triggers design review, containment and affected gate retesting. WAF/AI gateway alone cannot establish semantic safety. |
| ModelOps / evaluation owner | Monitor input/data drift, concept/performance drift when labels arrive, calibration and subgroup metrics, safety refusal changes, hallucination/grounding samples, retrieval freshness, embedding/index changes and tool behavior. | Compare to approved baselines and use-case thresholds. Investigate drift; it is a signal, not proof of degradation. Delayed labels and low sample sizes require explicit uncertainty. |
| Independent assurance | Run adversarial red teaming, application/infra pen testing and model/RAG revalidation at least annually as a proposed Institute baseline; shorten cadence for high-risk uses. Test before release and after material changes, incidents or credible new attack paths. | Track scope, independence, rules of engagement, findings, remediation and retest; governance renews or withdraws authorization. Annual cadence is a design proposal, not a blanket ISO or EU legal requirement. |
| Governance / compliance | Review intended-use changes, role/classification changes, supplier/GPAI changes, exceptions, oversight effectiveness, regulatory updates and any applicable post-market or incident-reporting duties. | Route reportable events to legal/compliance for jurisdiction-specific assessment and deadlines. Model, corpus, index, prompts, policies and tools all participate in change control. |
Telemetry contract
Every approved release defines a schema and retention schedule: timestamp, correlation ID, tenant or pseudonymous user ID, service identity, model/adapter version, prompt-template and policy version, corpus/index/embedding version, retrieved document identifiers or hashes, authorization outcome, gateway rule action, tool permission/outcome, token/cost metrics, latency, error and detection identifiers. Protect log integrity and access; use synchronized time and tested collection paths.
Avoid raw sensitive prompts, retrieved documents or secrets in the general SIEM. Minimize/redact events, apply data residency and retention controls, and retain necessary diagnostic samples only in restricted evidence storage with approved access. Preserve enough lineage to reproduce incidents without indiscriminate content collection. Define what happens if telemetry fails; high-risk workflows may need to stop or degrade safely rather than continue unobserved.
Drift and incident loop
Baseline approval → monitored signals → triage and human assessment → containment or rollback when necessary → root-cause analysis → remediation or candidate rebuild → targeted and regression assurance → renewed release decision. A drift alarm must not automatically authorize retraining or deployment. Preserve previous model, adapter, index, corpus and policy baselines so rollback restores the system configuration coherently.
08 / Evidence & change control
A release is a signed set of dependencies.
The minimum release manifest identifies product/intended use, accountable owner, repository commit, build and artifact digests, model/provider version, adapter, training/validation/test dataset versions, RAG corpus snapshot, chunking and embedding configuration, index version, system prompt, tool schemas/permissions, gateway policies, infrastructure configuration, evaluation results, exceptions, approval records, monitoring thresholds and rollback target. Protect manifests against alteration and bind decisions to their digests.
Evidence records capture test scope and environment, provenance, evaluator identity, independence, data partitions, metrics and limits, observed findings, remediation/retest, decision rationale and expiry. Record a negative result as evidence rather than overwriting it. The proposed class view supplies a starting schema; an implementation needs validated access controls, retention, signatures and audit trails.
Research questions for subsequent versions
- How should materiality thresholds differ for prompts, corpus updates, adapters and autonomous tool permissions?
- Which combinations of telemetry and sampled evaluation detect meaningful degradation without excessive content retention?
- How can retrieval ACL enforcement and explanation usability be independently measured across languages and tenants?
- Which tests and release conditions can be automated reliably, and which require accountable human judgment?
09 / Publication control
Research Version 0.1.0
| Version | Date | Status | Change |
|---|---|---|---|
| 0.1.0 | 24 October 2026 | Research version • initial release | Six UML views; G0–G7 gates; RAG/fine-tuning paths; ISO control cross-references; pre/post-release assurance and evidence model. |
Document ID: IAIGCRM-AI-LC-001. Research direction: Stephen Buerle, PhD, CISSP — Founder, Executive Director & Head of Research. Prepared with AI assistance for Institute review. Release status does not imply external peer review or completion of a production implementation.
Version policy: major revisions alter the architecture/gate model; minor revisions extend research coverage; patches correct presentation or non-material errors. Git records every publication change; published research versions retain their manifest and change history. Release manifest · Change history · Download research text · Version-controlled source ↗
10 / Sources & attribution
Standards inform the design; the synthesis is Institute research.
Primary sources checked 24 October 2026. Gate assignments, implementation mappings, evidence schema, thresholds and annual test cadence are proposed design choices. Follow current official sources and the licensed standards when implementing.