AI Integrations and API Map

How to use this document

• What it is for. This is a base register to document every connection between the organization's systems and AI services or models: what data flows, to which vendor and country, with which credentials, under what limits, what it depends on and who is accountable for it.
• Who should own it. Usually IT architecture. Each integration also has a technical owner and a business owner. Enter the function in [RESPONSIBLE FUNCTION] and the person in [OWNER].
• Decisions to take first. Decide where the register will be kept (spreadsheet, configuration management tool or repository), which integrations count as critical (Section 2.4) and who approves a new integration.
• Fields to complete. Complete one record (Section 3) per integration and summarize them all in the overview (Section 4). Sections 5 to 8 capture cross-cutting information. Never store secrets, keys or passwords in this register: only where they are kept and who manages them.
• Country variants. This register has no country variants. If there are international transfers of personal data, complete Section 5 with the transfer mechanism and, where the law requires it, the registration with each country's authority; see "Related regulatory references."
• Review. Have information security validate credentials and controls, and have the data protection officer validate personal data flows and transfers.
• Approval and publication. This is a restricted internal document. Have it approved by [RESPONSIBLE FUNCTION], record the approval in "Version history," and share it only with those who need it.

AI Integrations and API Map

Field	Value
Organization	[LEGAL ENTITY NAME]
Owning function	[RESPONSIBLE FUNCTION]
Register owner	[OWNER]
Approved by	[APPROVED BY]
Last update	[DATE]
Review frequency	[REVIEW FREQUENCY]
Document classification	Restricted internal use

1. Purpose and scope

1.1 This register documents the integrations, APIs, connectors, queues, orchestrators and agents through which the systems of [ORGANIZATION NAME] exchange data with AI services or models, whether in-house or third-party.

1.2 It is used to identify critical dependencies, review what data leaves the organization and where it goes, control credentials and costs, prepare incident response and vendor exit, and provide evidence in audits.

1.3 It covers:

• calls to model APIs (text, image and voice generation, embeddings, classification);
• connectors that give an AI service access to internal repositories (email, documents, CRM, knowledge bases);
• AI agents and the tools or actions they can execute;
• batch, file, webhook, streaming or queue-based exchanges;
• supporting services: vector databases, logging and observability, content filters, AI gateways.

2. Maintenance rules

2.1 No integration with an AI component goes into production without being entered in this register and approved by [RESPONSIBLE FUNCTION].

2.2 Changes to the endpoint, vendor, model, authentication, data sent or processing country are recorded before they are applied; if an emergency prevents this, within [COMPLETE: business days].

2.3 Retired integrations are marked "retired" with the date, confirmation that credentials were revoked and, where applicable, confirmation that the vendor deleted the data. They are not removed from the register.

2.4 An integration gets the critical dependency flag if it meets at least one of these criteria: its outage stops an essential business process or a customer service; it sends sensitive personal data or confidential information; it allows an agent to take actions with external effect (payments, shipments, changes to records); or there is no alternative within [COMPLETE: hours].

2.5 Integrations with the critical dependency flag always state their failure fallback, their upstream dependency and their safe degradation criterion, consistent with the "AI Rollback and Safe-State Protocol" and the "AI Failure Contingency Runbook".