Connector Risk Register: Vetting AI Integrations

A connector risk register is a running record that assesses every AI integration before it is switched on, documenting what data each one touches, where that data flows, and how long the vendor keeps it. It exists because a single connector can quietly move confidential information out of your control. Keep one simple table, review it before every activation, and treat default-on connectors as the risk they are.

What is an AI connector risk register?

An AI connector risk register is a single running document that lists every integration between your AI platform and an outside system, records what data each one can reach, and states whether it was assessed and approved before use. Think of it as a guest list for your data. Nothing gets in without being written down first.

Each row is one connector: a link to your CRM, your document storage, your analytics, your ad accounts, or your email. For each, you capture the highest data class it can reach, the direction of access, the vendor's retention posture, and a plain approval decision. The register lives where the team can find it, and one named owner keeps it current. It is deliberately boring, because boring is what survives an audit. The highest data class a connector touches is where the register meets your green, yellow, and red data classification framework, which supplies the labels the register is written in terms of.

Why does a connector risk register exist?

It exists because a single connector can move sensitive data out of your control faster than any person could, and usually without anyone noticing. The register turns that invisible risk into a visible list.

Connectors are convenient, and convenience is exactly the danger. One integration switched on to save five minutes can expose confidential client data to a vendor whose retention terms nobody read. Before a register exists, the honest answer to "which outside systems can our AI read from?" is usually "we are not sure," and that answer is a problem on its own. Regulated data, client confidential material, and personal information all carry obligations that do not disappear because a tool made access easy. The register is how you keep those obligations in view instead of discovering them after a breach. It is also the difference between saying your integrations are safe and being able to show it.

How do you assess an integration before switching it on?

You assess an integration by answering four questions before activation: what data it can touch, which direction access flows, how long the vendor retains it, and whether that combination is acceptable for the most sensitive data class involved. Only after those four answers are on the record does the connector go live.

The order matters, because the sensitivity of the data sets the bar everything else has to clear. Classify first: identify the highest tier the connector can reach. A connector that only touches green, shareable data can often be approved quickly. A connector that can reach red data, confidential client information and personal data, never gets switched on casually and never gets its access used without a deliberate, documented decision.

Then check direction. Read-only access is a lower risk than access that can write back into a source system, because write access means the AI can change the systems your business runs on, not just read from them. After direction, check retention: does the vendor train on your data, how long do they hold it, and can you have it deleted. The assessment ends in a documented decision that is a yes, a no, or a conditional yes such as read-only, or green data only. Conditional approvals are common and healthy, because they let you use a connector for what it is safe for while fencing off what it is not.

What is retention and data-flow posture, and why track it per connector?

Retention and data-flow posture is the record of what a vendor does with your data once a connector hands it over: how long they keep it, whether they use it to train models, and whether you can get it deleted. You track it per connector because every vendor answers those questions differently, and the weakest one sets your real exposure.

Two connectors that look identical from inside your workspace can carry opposite retention terms. One deletes on request within days and trains on nothing. Another retains indefinitely and reserves training rights in its default settings. If you only track connectors as on or off, you lose that distinction, and the distinction is the whole risk. Posture also covers direction and destination. A read-only connector that pulls reference material into a workspace is a different animal than one that can write finished output back into a client-facing system.

Tracking posture per connector is what lets you say, with evidence, that confidential data never crossed into a system that would retain or train on it. For any firm running many client accounts through the same platform, this ties directly to keeping accounts sealed, which is covered in white-label data segregation. A connector with loose retention is a leak waiting to cross an account boundary, so posture and segregation are checked together.

Why are default-on connectors a quiet risk?

Default-on connectors are a quiet risk because they grant access you never actively chose, which means they never went through assessment and never earned a row in the register. Access nobody decided to grant is access nobody decided was safe.

Many platforms ship with integrations enabled, or one click from enabled, presented as a helpful convenience. The convenience is real, but so is the exposure, and the quiet part is what makes it dangerous. Loud risks get attention. A default-on connector produces no alert, no approval step, and no line in any record. It simply works, which is precisely why it slips past governance and keeps working until someone asks a question the logs cannot answer.

The fix is a standing rule: every connector stays off until it earns a row in the register, and the platform's own permission and visibility controls enforce that default rather than a policy that depends on memory. Private versus organization visibility, role-based access, and provisioning are where this rule actually lives. When the default is off and the controls hold it there, turning a connector on becomes a deliberate act that leaves a trace, which is the entire point.

What does a simple connector register look like?

A simple connector register is one table any team can keep, with a single row per connector and a handful of columns. You do not need a governance platform to start. A shared spreadsheet is enough, and starting there beats waiting for tooling you will outgrow anyway.

A workable set of columns:

• Connector name and the outside system it links to.
• Highest data class it can reach on the green, yellow, red scale.
• Access direction, read-only or read and write.
• Vendor retention posture, including training use and deletion rights.
• Approval decision, a yes, no, or conditional, with the condition stated.
• Owner, the named person accountable for the row.
• Last reviewed, so stale entries are obvious.

Keep the columns few enough that people actually fill them in. A register nobody updates is worse than none, because it creates false confidence. The discipline is in reviewing it on a set cadence and before any new connector goes live, not in the sophistication of the tool. When a connector can reach regulated or confidential data, add a human-in-the-loop step so a person signs off before that access is used, not after. That validation step surfaces the content for required review and speeds the sign-off along, but it never replaces the human making the call.

How does the register fit the wider governance model?

The connector risk register is one layer of a governance model delivered as a working artifact, sitting alongside data classification, white-label segregation, and human-in-the-loop validation. Each layer reads from the same native controls, so the register is not a standalone spreadsheet bolted to the side of your platform. It is wired into the permissions that already gate access.

This is also where honesty matters more than reassurance. Governance is built inside the AI platform's native controls: permissions, private versus organization visibility, single sign-on, provisioning, and role-based access. But some deeper controls sit at higher plan tiers, including centralized audit logs, compliance APIs, and regulated-industry readiness, and some agentic activity may not appear in standard audit logs at all. A register you control gives you a record that does not depend on what a vendor's logs happen to capture. Activity can be streamed to a security monitoring system for visibility, which helps, but streaming visibility is not the same thing as audit logging, and it is dishonest to present one as the other. The register is the part of the model that stays true regardless of what the platform can prove, because it lives with you.

None of this is theory. The register described here is part of a governance framework already in use, not aspirational, running real client workflows today on a gated, multi-step build that parses and quality-checks data before any client-facing output is produced, and supported by a library of more than 50 custom, disk-verified skills refined against real marketing deliverables. For the full picture of how these layers ship together, see governance delivered as a working artifact.