Technology & Platforms ยท TEC-04
Integration with existing systems
AI is connected to core systems through supported, documented interfaces that the organisation can maintain, change and switch off.
Why it matters
AI is most useful when it works with the systems people already use, but informal connections break silently, are hard to change and can become critical without anyone noticing. Supported and documented integration keeps AI services maintainable and lets them be removed cleanly.
Levels
| 0 Absent | Confirmed absent: the evidence shows nothing is in place. Not known is recorded as insufficient evidence, not 0. |
|---|---|
| 1 Initial | AI is connected to other systems by whatever means works, often manual workarounds or unsupported links. |
| 2 Developing | Some integrations are documented and supported, but others are informal or known only to the people who built them. |
| 3 Defined | Every integration between AI and core systems is supported, documented and can be switched off safely, and AI permissions on other systems are limited and approved. |
| 4 Managed | Integration health and failures are tracked, undocumented integrations are found and brought under control, and changes go through managed change. |
| 5 Optimising | Integration patterns are standardised and reused, and improved from incidents and change experience. |
Level 3 criteria
Level 3 is met when every applicable criterion is met. Criteria marked with an overlay apply only to organisations with that characteristic (overlays).
- TEC-04.1 Every integration between AI and core systems uses supported interfaces.
- TEC-04.2 Each integration is documented with its owner and data flows.
- TEC-04.3 Each integration can be disabled without disrupting the core system.
- TEC-04.4 The permissions and actions an AI system or agent holds on other systems are limited to what its purpose needs.
- TEC-04.5 Those permissions and actions are approved and risk assessed.
Assessment questions
- How is this AI service connected to the systems it reads from and writes to?
- Where are those integrations documented, and who supports them?
- If you had to switch the AI service off tomorrow, what would break?
- Integration documentation showing interfaces, data flows and owners
- Support arrangements for AI integrations
- Permission and action limits for AI systems and agents, with approvals and risk assessments
How to reach Level 3
- Require every integration between AI and core systems to use supported interfaces.
- Document each integration with its owner and data flows.
- Design and test a way to disable each integration without disrupting the core system.
- Limit the permissions and actions each AI system or agent holds on other systems to what its purpose needs, and get them approved and risk assessed.
Common pitfalls
- Giving an agent write access to a core system when read access would do.
- Never testing the switch-off, so nobody knows whether it works.
Starter artefacts
- Integration register with owners and data flows
- Permission approval record for AI systems and agents
Ownership and sequence
- Accountable
- delivery lead
- Contributors
- data owner, business owner
- Depends on
- TEC-02
- Roadmap step
- 2
- Lifecycle
- acquire_build, deploy, operate, retire
Cross-references
| AI Cyber Security Code of Practice | 2.6 direct; 4.1 partial; 5.1 partial; 6.1 partial |
|---|---|
| Algorithmic Transparency Recording Standard | Tier 2 Deployment context partial; Tier 2 Tool specification partial; Tier 2 Operational data specification partial |
| EU AI Act | Art 14 partial |
| JSP 936 Part 1 | para 82 partial |
| MITRE AI Maturity Model | P4.3 partial; P6.1 partial |
| NIST AI RMF 1.0 | MANAGE 2.4 partial |
| UNESCO AI Maturity Framework | 3.3 direct; 4.3 direct |
direct: this control at Level 3 meets the item. partial: it covers part of it.