Identity and tenancy
Propagate the authenticated user, organisation, role, purpose, and policy; enforce access at the source or trusted service rather than in prompts.
Enterprise AI architecture
How should enterprise AI connect to existing systems?
Keep systems of record authoritative. Place AI behind explicit identity, data, tool, and policy boundaries; separate retrieval from action; expose narrow versioned interfaces; verify resulting state after writes; and design observability, fallback, and revocation before expanding authority.
By Onyx Devs Lab · Published · Updated
AuthoritySystems of record remain authoritative
InterfacesVersioned reads, tools, events, and contracts
ControlApprove, execute, verify, audit, recover
Build a governed context path
The model should receive only the context required for the current authorised task.
Data contracts and retrieval
Define object identities, fields, meaning, freshness, provenance, permissions, citation, missing-data behaviour, and version compatibility for every source.
Boundary services
Use adapters or services to normalise legacy APIs, databases, files, events, and vendor systems while preserving rate limits, ownership, audit, and change isolation.
Treat actions as controlled transactions
A model suggestion is not proof that a business action was valid or completed.
Narrow tools
Expose typed, purpose-specific operations with validation, least privilege, limits, dry-run support, and deterministic policy checks.
Approval and execution
Bind confirmation to the exact target and payload, prevent stale or duplicate actions, serialise conflicts, and record actor, reason, request, result, and policy version.
State verification and recovery
Read back the system of record, detect partial failure, reconcile uncertain outcomes, retry idempotently, alert owners, revoke authority, and preserve manual fallback.
How to design the controlled integration path
Map systems and trust boundaries
Inventory sources, owners, identities, interfaces, data classes, network zones, read and write paths, rates, failure modes, and systems of record.
Define canonical contracts
Version the entities, events, tools, permissions, errors, freshness, provenance, and compatibility rules used by the AI layer.
Deliver a read-only vertical slice
Prove identity, retrieval, citations, latency, monitoring, and business usefulness before enabling consequential actions.
Add writes by authority tier
For each action, add validation, confirmation, idempotency, audit, state verification, rollback or compensation, limits, and revocation.
Frequently asked questions
Should the AI connect directly to the production database?
Usually expose a controlled read or service layer. Direct access can bypass business rules, tenant controls, audit, rate limits, and safe schema evolution.
Is RAG the integration layer?
No. Retrieval supplies context; integration also includes identity, contracts, workflows, tools, events, write control, resulting-state verification, monitoring, and recovery.
How should legacy systems be handled?
Use supported APIs, replicas, exports, queues, gateways, or narrow adapters according to risk. Record ownership and failure behaviour instead of hiding legacy constraints.
Start with one concrete operating problem.
We will first clarify the workflow, evidence, data boundary, and outcome standard before recommending the next step.
Contact Onyx