Architecture and operating model
Enterprise AI governance is a lifecycle that connects purpose, data, model, prompt, tool permissions, evaluation evidence and production telemetry in one change chain. The idea stage names the business owner and affected users; design establishes data classification and trust boundaries; pre-production gates require quality, security, cost and rollback evidence.
The control plane remains with the organization even when model providers change. Model cards, data-source records, prompt versions, evaluation results, risk acceptance and deployment identity are linked. A high-impact decision workflow can require human approval, appeal and retention controls, while a low-impact summarizer can use a lighter but still measurable control set.
Production governance uses measurable gates rather than a static document. Quality drift, source changes, new tool permissions, model upgrades or regulatory impact trigger reassessment. Ownerless models, purpose expansion and shadow AI make technical risk invisible when they remain outside the inventory.
- 1Purpose and risk tier
- 2Data/model/prompt inventory
- 3Evaluation and authorization gates
- 4Production monitoring and reapproval
Design parameters
- Use-case record
- Define the decision, user, prohibited uses and success measures in one record.
- Risk tier
- Classify impact, data sensitivity, autonomy and reversibility as low, medium or high.
- Evidence bundle
- Link model, data, prompt, eval, red-team, cost and approvals to the deployment identity.
- Change trigger
- Require retesting when model/data versions, tool permissions or thresholds change.
Worked example
For an HR assistant, build a 240-question golden set with thresholds of 92% factual correctness, no more than 2% unsupported answers and zero personal-data disclosures. A candidate model scoring 94% correctness but 4% unsupported answers fails the gate until retrieval or response policy is corrected and the same versioned set is rerun.
At 80,000 monthly requests, a 1% stratified human review samples 800 records. High-risk payroll questions are sampled at 100%. Each event carries model, prompt, source and policy versions so incidents are not attributed to the model alone.
Example commands: replace lab values and confirm permissions and software versions before use.
ai-release validate --manifest release.yaml --eval-set hr-golden-v3
ai-release approve --risk-tier high --evidence evidence.json
ai-release deploy --id hr-assistant-2026-10-25 --canary 5%Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Results cannot be reproduced | Prompt, model or retrieval versions are missing. | Check deployment identity and the dependency manifest for the same input. |
| Shadow AI adoption increases | The approved path is slow or inventory visibility is incomplete. | Compare network/SaaS inventory with access logs and provide a safe request path. |
| Quality degrades silently | Production distribution differs from the golden set or sources changed. | Relabel live samples by risk stratum and add them to regression tests. |
Acceptance checks
- Record business, technical and risk owners for every system.
- Verify data classification, retention and fields sent to model providers.
- Pin model, prompt, retrieval and tool versions under one deployment identity.
- Run quality, security, cost and latency gates before production.
- Exercise human intervention and rollback procedures.
- Link change and incident records to periodic management review.
Related concepts
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. A test environment that does not reflect production can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.