At a global medical device company, the legal team could tell you exactly where every piece of its privacy work lived. Privacy review ran in one system. Transfer assessments sat in another. The record of processing activities was a spreadsheet one person kept current. AI vendor diligence landed with whoever noticed it first.
Every assessment had an owner and a home, and the team was good at the work. They wanted one intake that fired the sub-assessments itself, so one question about one new tool became one piece of work, routed once.
The rate is the problem. New tools arrive faster and plenty of them arrive already in use, bought on a corporate card or signed up for with a work email weeks before anyone thought to ask legal.
An AI governance intake is the single structured entry point that catches those requests and routes each one to the assessments it triggers, while your answer can still change what happens.
One thing first, because every lawyer asks it. Routing is mechanical. Deciding whether a DPIA is legally required is judgment, and that call stays with you. The intake’s job is to get the question in front of you early, with the facts attached.
GC AI is the enterprise-grade legal AI platform a three-time general counsel built for in-house teams, now used by more than 2,000 legal departments, including 200+ public companies such as Columbia Sportswear and Interface.
Every request that clears the form turns into legal work: a DPA to read against Article 28, a DPIA screen to research, a ROPA entry to draft.
GC AI is built for that half of the job, with Playbooks for vendor DPA review inside Word and prebuilt privacy workflows in the Skill Library.
Which AI Rules Your Intake Has to Catch
If you stopped tracking AI compliance deadlines, that was fair. The big one moved.
The Digital Omnibus on AI, endorsed by the European Parliament and the Council in June 2026, moved the EU AI Act’s obligations for standalone high-risk systems under Annex III from August 2, 2026 to December 2, 2027, and product-embedded systems under Annex I to August 2, 2028. That is the part of the Act in-house teams had been preparing for, and it now lands sixteen months later than planned.
Article 50 kept its original date, and it got much less attention. Article 50 transparency obligations apply from August 2, 2026, and they attach to any AI system that interacts directly with people, whatever its risk classification.
A customer-facing chatbot is in scope whether or not you have a single high-risk system anywhere in the company. You have to disclose it before or at the very start of the conversation. The Omnibus moved one piece of Article 50, the machine-readable content marking, to December 2, 2026. The ceiling on Article 50 is 15 million euros or 3% of worldwide annual turnover.
The US picture rearranged the same way. Colorado repealed and reenacted its AI Act through SB 26-189, signed May 14, 2026 and effective January 1, 2027, trading the high-risk framework for rules on automated decision-making technology used in consequential decisions. California’s ADMT regulations under the CCPA took effect January 1, 2026, with the ADMT compliance date set at January 1, 2027.
Here is the part that survived every rewrite:
Colorado requires developers and deployers to retain the records that demonstrate compliance for at least three years.
California requires the risk assessment behind a covered activity, and for assessments conducted in 2026 and 2027 the documentation goes to the CPPA by April 1, 2028.
The EU AI Act has providers of high-risk systems keep technical documentation for ten years after a system reaches the market.
Legislators softened the substantive duties, delayed the hard ones, and narrowed the scope. All three kept the requirement to show your work.
That is the reason to build the intake now. It produces a record before anyone asks for one.
Which Privacy Assessment Fires When a Request Comes In
An intake runs on routing logic: a map from a trigger event to the assessment it sets off, with the legal hook attached so nobody relitigates it later.
Trigger event | What it sets off |
A new vendor or sub-processor starts processing personal data | Vendor and DPA review under GDPR Article 28, plus a ROPA entry under Article 30 |
Processing likely to result in a high risk to individuals | DPIA under Article 35 |
Personal data moves to a country with no adequacy decision | Transfer impact assessment alongside the transfer mechanism |
A new AI model or AI vendor enters the stack | AI vendor diligence, plus a DPIA screen where the use touches personal data |
An AI system starts interacting directly with customers | Article 50 disclosure review, live as of August 2, 2026 |
An automated system starts influencing a consequential decision | Pre-use notice and a three-year record under Colorado’s ADMT law, and a risk assessment under California’s |
Any new processing activity, including a purely internal one | ROPA update under Article 30 |
Real requests trip several rows at once.
A new AI vendor processing customer data across borders sets off a DPA review, AI vendor diligence, a DPIA screen, a transfer assessment, and a ROPA entry from one submission.
The routing table holds that complexity so the form does not have to. The submitter answers in business terms and the logic does the rest.
Routing tells you which assessment applies. Tiering tells you how much of it to run, so a meeting-notes summarizer does not get the same treatment as a hiring model:
Anything that interacts with customers or the public, or that influences a decision about a person, gets the full review before go-live. This is the tier where Article 50, Colorado’s ADMT rules, and California’s risk assessment all land.
Anything that touches personal data without reaching that bar gets a DPIA screen and a ROPA entry.
Everything else gets a ROPA line and a named owner, and stops there.
The NIST AI Risk Management Framework and the EU AI Act both assume you are working this way. It also keeps people using the intake instead of going around it.
What to Check on a Vendor’s Subprocessor List
The DPA tells you what the vendor promises. The subprocessor list tells you who else touches the data, and with an AI vendor that is where the model providers sit.
A vendor that names three LLM providers has three sets of terms behind its one signature, and a change at any of them can move your transfer analysis. Whether you hear about it depends on what your contract requires.
Five things to check on any subprocessor list:
Whether it is public or gated behind an NDA.
Whether each entry states a purpose and a location, or nothing but a company name.
Whether your contract gives you notice and objection rights when the vendor adds one.
Whether the model providers are on a zero data retention footing or only a no-training assurance. Those are different commitments.
Whether any single entry carries a condition on it.
GC AI is a vendor too, so it is fair to hold us to the same standard. Any team running this intake would have to run GC AI through it, which is why our list is public instead of available on request. Picking a platform raises different questions than clearing one through privacy review, and we cover those in how to evaluate legal AI vendors.
Our subprocessor list is public, no NDA, currently stamped with the last date it changed.
It names six AI providers processing customer content on a zero data retention basis: OpenAI, Anthropic, Reducto, Cohere, Google, and xAI.
One of those entries carries a condition, which is the fifth item on the checklist above. The Anthropic line applies when Claude Fable 5 and newer models are not enabled on your account. Check the same line on any other vendor’s list. More on what to look for sits in our AI DPA review checklist and in what to know before signing a legal AI contract.
Why Privacy Review and AI Diligence Sit in Different Systems
Two categories of tool exist, and lean teams work in the gap between them.
Legal intake tools cover the front door. One place to submit a request, with conditional routing behind it.
Privacy platforms cover the assessment engine, with auto-triggered DPIAs and generated ROPAs. They are built for a company that has a privacy office to run them.
A team where privacy is one of ten hats works in the gap between the two, stitching the ends together by hand. That is how assessments slip, and how a regulator later finds a processing activity missing from the record.
There is a second reason the gap persists, and it sits with people rather than software. Some of the people best placed to fix this have already sponsored one system that landed badly, and they remember what that cost them internally. Proposing a new intake is a harder ask when you are the person who championed the last one.
Efficiency was the argument last time, which is exactly why it lands flat now. The argument that holds up is the record. A routed intake leaves one, and that record answers the question when somebody upstairs asks who approved this and when.
How to Build an AI Governance Intake in Five Steps
Every step below runs on tools you already have.
Put up one form anyone in the company can reach, holding it to questions a non-lawyer can answer without a call. Seven cover it:
What is the tool or vendor, and is anyone using it already?
What will it be used for, in one sentence you would say out loud?
What data goes into it: customer personal data, employee data, special category data, confidential business data, or none of those?
Where is that data processed and stored, and which sub-processors touch it?
Does the output influence a decision about a person, such as hiring, pay, credit, benefits, or discipline?
Does it interact directly with customers or the public?
Who owns this on the business side, and what is the target go-live date?
Map each answer to the assessment it triggers, using the table above as your starting logic. A cross-border answer flags a transfer assessment. A new model flags AI vendor diligence. High-risk processing flags a DPIA screen for a lawyer to confirm or clear.
Name a person for each assessment type and put that name on the routing table. “Legal is reviewing it” leaves the business guessing about who to chase.
Set a first-response target and publish it, so the business treats the review as a gate with a clock. A published target gives people a reason to use the front door.
Log the decision, the date, the person who made it, and the reasoning, then write the closed request back into the ROPA as part of closing it rather than as a quarterly cleanup project.
That last step is the deliverable. Colorado puts a three-year floor under it, and California expects the assessment behind it on a schedule. Routing solves the easy half. The record is what carries you through an audit.
A form, a routing table, four named owners, and a log will do it, and a spreadsheet version you stand up this quarter beats a platform you buy next year.
What to Do About the AI Tools Already in Use
An intake catches what arrives next. The tools already running need their own pass, and that list is usually longer than anyone expects.
Start with the systems that already know. Expense reports, the SSO tenant, and the browser extensions IT can see will get you a first inventory without asking a single person to self-report.
Then run the same routing table across it, highest risk first. Most entries need a ROPA line and nothing more. A few will surface a vendor processing personal data across borders with no DPA on file, and those are worth the assessment time now rather than at renewal.
The contracts behind those vendors are the other half of the inventory. With Contract Intelligence you can put the whole set in one place and ask across all of it at once, so “which vendor agreements have a DPA on file” and “which ones permit transfers outside the EEA” become questions you answer against the full contract base, with every answer cited to the document it came from.
That inventory is worth building for a second reason. Several of the rules above assume you already have one.
How GC AI Handles the Assessment Work
Ali Hartley, Chief Legal Officer at SimplePractice, described her company’s version of this on the CZ and Friends podcast:
“My security team has now built this really awesome prompt for vendor reviews. They’re using AI as sort of that first step in a vendor review… previously, I think they told me it used to take over like between three to six hours per vendor review. And now it’s down to less than 30 minutes.”
You can build the routing yourself. The assessments are what take lawyer hours, and that is the half GC AI works on:
Research whether a DPIA is required for a specific processing activity, and get the answer with citations you can check.
Run a new vendor’s DPA against GDPR Article 28 using Playbooks in Word, against your own standard positions rather than a generic checklist.
Draft the assessment memo and the ROPA entry from the facts already captured on the form.
Keep the routing table current with the Regulatory Monitoring Skill in the Skill Library, which scans the jurisdictions and risk areas you select, checks each flagged change against the bill or regulation itself, and returns a prioritized list of what to act on.
Answers carry Exact Quote citations back to the source document, which matters when the output goes into a record a regulator may read. There is more on running that kind of watch in our guide to AI for compliance monitoring.
The threshold call stays yours. GC AI does the work that gets you ready to make it.
Frequently Asked Questions
Do You Need a DPIA for ChatGPT or Microsoft Copilot?
The answer depends on the data you put into it. A DPIA is required under GDPR Article 35 when processing is likely to result in a high risk to individuals, so a general assistant used for drafting on non-personal data may sit below that bar, while the same tool connected to customer records, HR files, or special category data usually clears it. The workable default in an intake is to flag every new AI tool for a DPIA screen and let the reviewing lawyer clear it or escalate. The screen takes minutes, and it catches the cases that would otherwise surface in an audit.
What Is the Difference Between a DPIA and a Transfer Impact Assessment?
They answer different questions about the same processing. A DPIA under Article 35 asks whether a high-risk use of personal data is justified and how the risk gets mitigated. A transfer impact assessment asks whether personal data stays adequately protected once it moves to a country with no adequacy decision, and it sits alongside the transfer mechanism rather than replacing it. One new AI vendor storing data in the US can require both, plus a ROPA entry under Article 30.
Who Approves New AI Tools, Legal or IT?
Both, in practice. Security and IT own the technical assessment, legal owns the privacy and contractual analysis, and the business owner stays accountable for the use case. The programs that work name one person accountable end to end, so every request has an owner rather than a committee. An intake form is how that shared review runs on one record instead of three parallel email threads.
Can You Run an AI Governance Intake Without Buying Software?
Yes, and that is a reasonable place to start. A reachable form, a documented trigger-to-assessment map, a named owner per assessment type, a published response target, and a decision log will hold up, and all five can live in tools you already have. Software earns its place when volume outgrows what one person can track by hand, or when you need the assessments themselves worked faster rather than only routed.
