Client AI-Permission Register
What breaks
Clients are writing AI clauses into master service agreements (MSAs) now: no-training guarantees, disclosure requirements, named model restrictions, audit rights. The rules live in contract PDFs, and the decisions get made by a copywriter at 9pm choosing which tool to open. The answer to "can we use AI on this account" depends on who you ask.
What gets built
Extract each client's AI restrictions from the executed MSA and SOWs into structured fields on the client record: permitted providers and tiers, whether confidential material may be entered at all, whether output may reach production, whether disclosure is required, who signed off. Then surface those fields as a blocking check inside the tools where the work happens. In a contracts folder they reach nobody.
What already solves this
Nothing sells this. Data loss prevention gateways block domains but have no concept of a per-client rule, because they do not know which client a piece of work belongs to. Enterprise AI tenants give you the no-training terms and the audit log, but enforce one policy per tenant. Contract lifecycle tools extract clauses and stop at the repository. The register sits between four systems, which is why it does not exist.
Opens onto: A governed AI workspace with provenance logging, an approved-tool register, and then every downstream build with a defensible answer to "whose consent covers this".
Every other AI project
Depends on this existing first. It is the consent gate the rest of the work has to clear.
Client confidentiality and data handling practice