Bringing AI into enterprise systems without creating an ungoverned parallel system

The risk: a parallel system without an owner

An assistant often starts with a few documents and an API key. It becomes useful, gains CRM access, remembers conversations and triggers actions until it carries part of a business process. If these extensions escape information system governance, the organisation acquires a second system: duplicated data, implicit identities, poorly understood dependencies and operations without an owner. A CIO’s task is to decide how the new capability joins the existing system.

Our engineering recommendation is to treat AI as an information system component. The model provides a probabilistic capability; contracts, permissions, states and service commitments remain explicit. The following is a design method, not a report of measured Digital Place project results.

Start with the service and its responsibilities

Describe the service first: user, triggering event, required data, expected output, possible action and degraded mode. A case preparation assistant can produce a sourced summary without permission to modify the case. An automated classification service can suggest a category without deciding to reject an application. These distinctions establish boundaries before selecting a model or framework.

Assign business, technical and operations owners. Specify who approves a new source, permission or behaviour. The NIST GenAI profile provides a risk management reference; applying it requires local, verifiable decisions.

Contracts the information system can use

Put a service API in front of the AI runtime. Version inputs, output schemas, errors and idempotency rules. Schema-valid JSON may still be wrong: complement schema validation with business checks, source references and explicit handling of unknown values. Keep consumers independent of any supplier’s response format.

OpenAPI describes HTTP interfaces. The contract should also define size limits, timeouts, retries, cancellation and asynchronous delivery where needed. After a write times out, check operation state before retrying: another attempt must not create another business commitment.

Data and RAG: govern retrieval

Use document retrieval when answers depend on internal or changing information. RAG does not automatically repair source quality: inventories, owners, dates, permissions and deletion remain necessary. Retain references to the document and passage used; test missing results and conflicting sources too.

Apply permissions during retrieval. A shared index that reveals a document to an unauthorised user leaks data even if the answer sounds helpful. Propagate access withdrawal and deletion into indexes and caches. Treat retrieved content as untrusted data, never as an instruction that can expand permissions.

Identities and action authorisation

Separate user identity, service identity and the delegation granted to an agent. Every tool should check authorisation against the target resource with a limited scope. A broad token in a prompt is not controlled delegation. Keep secrets server-side, with rotation and an explicit intended recipient.

For MCP connectors, the 2025-11-25 authorisation specification describes HTTP transport mechanisms. It does not replace business authorisation within each tool. Check sensitive actions at execution time; human approval should bind exact parameters to an operation whose state is still valid.

Interchangeability needs behavioural evidence

Isolate providers behind a narrow adapter covering invocation, structured outputs, tools, errors and usage accounting. Version prompts, policies and evaluation datasets as artefacts. Test an alternative model against the same scenarios and record differences in quality, latency, capabilities and data handling terms.

Compatible APIs do not ensure equivalent behaviour. Reversibility also requires data export, index reconstruction, repeatable evaluations and deletion of supplier-held copies under contractual terms. Establish a practical exit before supplier-specific optimisations become indispensable.

Cost and runtime: measure the completed case

Track cost per completed task, end-to-end latency, tool calls, retries, context consumption and escalations. Low token prices can conceal long workflows or extensive human rework. Test realistic workloads with long documents, slow tools and queues; set per-run call, time and spending budgets.

Choose the simplest path meeting acceptance criteria: a deterministic rule, search, extraction, a model call or a bounded agent. Provide a circuit breaker and manual mode. When a dependency fails, the service should communicate its limit and retain coherent state instead of inventing certainty.

Useful observability with data minimisation

Correlate requests, retrieval, model calls, control decisions and tool execution. OpenTelemetry HTTP conventions provide instrumentation references; GenAI conventions now evolve in their dedicated repository. Pin a version and avoid treating an experimental convention as a durable contract.

Traces should support diagnosis without becoming a second personal data store. Record version identifiers, durations and control reasons; minimise content and mask secrets. Define access, retention and incident procedures before enabling detailed capture.

Evaluation, CI/CD and operations

Create representative scenarios: correct answers, absent sources, denied access, injection, tool failures, recovery and cancellation. Test schemas and controls deterministically; repeat model trials to assess variability. Separate development and validation sets, and examine failures by severity rather than reducing them to a single average.

Treat a model, prompt, index or tool change as a software change. Pipelines, versioned artefacts, evaluation, gradual rollout and rollback should cover the entire service. The NIST AI SSDF profile helps place secure development within the lifecycle.

An explicit release decision

Before opening the service, ask for evidence at every boundary: stable contracts, tested access, identified data, verified budget limits, tested adversarial scenarios, clear operational responsibilities and rehearsed recovery. Define service SLOs, suspension criteria and reassessment frequency. A successful demonstration alone proves none of these.

AI can then join the information system with its strengths and limits understood. For Digital Place, engineering fundamentals make that integration controllable: a responsibility, interface and evidence at each significant boundary.