In an AI vendor risk assessment of an identity partner, a defensible answer to "is your team using AI on our data?" separates workforce identity data from consumer and regulated records, bounds why any production data is needed, keeps AI off your systems' write path, detects prohibited data on input, and proves afterward what was handled.
Identity work has an awkward property that most of IT does not share. The raw material is the sensitive data.
A network engineer can troubleshoot a routing problem without ever seeing a patient record. But an identity engineer building a correlation rule is working inside the HR extract. Someone designing a joiner-mover-leaver workflow is holding the termination file. An access model is, by definition, a map of who can reach what.
So when the question comes up, and it is becoming a standard vendor review question, "is your team using AI on our data?" is a harder question in identity work than almost anywhere else in the stack. It deserves a better answer than a blanket yes, and a better answer than a blanket no.
Here is what a defensible answer looks like.
Not all identity data carries the same risk
Consider a hypothetical. A health system sends over a user extract to support an application onboarding. It contains exactly what was requested: usernames, departments, job titles, and the entitlements each account holds. It also contains, a few columns over, patient identifiers those accounts had touched.
Nobody did anything wrong. The report was built years ago for a different purpose, and the extract inherited its shape. But the engineer who opens that file now has a decision to make, and if the only rule in their head is "do not share client data," they have no way to make it well.
A common mistake in these conversations is treating "client data" as one undifferentiated category. It is not, and the distinction matters enormously.
Workforce identity attributes are operational metadata: usernames, UPNs, employee IDs, job titles, departments, manager relationships, group and entitlement names, tenant identifiers. They are the substance of identity engineering, and you cannot design an access model without them.
Patient rosters, member files, subscriber lists, account numbers, Social Security numbers, dates of birth, home addresses, and diagnoses are something else entirely. Our position is that no vendor assurance, no contractual language, and no enterprise tier of any AI product makes them appropriate material for a model in identity work. The regulations behind them attach safeguards to any use, and convenience is not one of them: HIPAA's minimum necessary and de-identification standards at 45 CFR 164.514(d) and 164.514(a)-(b), the GLBA Safeguards Rule's service-provider oversight requirement at 16 CFR 314.4(f), the security requirements of NIST SP 800-171 for controlled unclassified information, and the information protection program NERC CIP-011 requires for BES Cyber System Information (Requirement R1).
The useful test is not a memorized list. It is a single question: is this person a member of the workforce, or a consumer of the business?
Employees, contractors, administrators, and service accounts are the subject of identity work. Patients, members, customers, and subscribers are the subject of the business. Consumer records do not belong in identity engineering artifacts at all, even when they arrive in the same extract as the workforce rows. If an export contains both, the right response is a filtered re-extract, not a careful promise to ignore the wrong half.
Ask your partner to state that test back to you. If the answer is vague, the line probably has not been drawn yet.
Schema is not data
Here is the practical point that collapses most of the debate.
You can design a lifecycle workflow, a correlation rule, a separation-of-duties policy, or an entire role model against synthetic records that match the production schema exactly, down to the messy optional attributes. The logic does not know or care whether the row behind it describes a real person.
The configuration is the deliverable. The records were only ever scaffolding.
That reframes the whole conversation. Where synthetic records are enough, they should be the default, and much of design work falls in that category. The question to ask is not "will you protect our data," it is "what do you need, and why?"
There are honest answers to that. Reconciliation against real population counts. Debugging a correlation failure that only reproduces on live data. Those answers should name a specific task, a specific field set, and a specific end point. Workforce identity data handled that way, under your data processing agreement and minimized to the fields the task needs, is ordinary identity engineering. What you are listening for is whether the scope is bounded, or whether "we need the data" is simply the default working mode. Consumer records and the prohibited classes above never belong in that scope at all.
The write path is the whole ballgame
If you ask only one question, ask this one. Can the AI authenticate to our identity platform?
An AI system holding credentials to your IGA, your directory, or your privileged access vault is a privileged identity. Unless you have onboarded it as a governed machine identity, in your own governance terms it has no manager, it will not appear in an access certification campaign, it has no termination date or lifecycle state, and nobody is accountable for its entitlements at review time.
That is every condition your identity program exists to prevent, reintroduced through the side door and justified by efficiency.
The defensible model is straightforward. AI-assisted work produces artifacts: configurations, rules, policies, documentation, test plans. A named human engineer reviews each one and ports it into your environment through your existing change process. That human step is not friction to be optimized away. It is the control, and it is what keeps an accountable person in the chain of custody between a generated artifact and a production entitlement.
When a vendor describes automated deployment into your tenant as a selling point, the governance question is not "is the AI any good." It is "who owns that service account at the next access review, and what happens to it when this engagement ends?"
Detection beats trust
The failure mode here is almost never malicious, and if this has happened on your team, you are not alone.
It is a capable, well-intentioned engineer at six in the evening, pasting a real extract into a tool because reproducing it synthetically would take fifteen minutes they do not have. The policy was read. The training was completed. Neither survived contact with a deadline.
Put plainly: a control that depends on every person remembering it under pressure is not a control. It is a hope with documentation.
What works is screening on the input side, purpose limitation scoped to the specific engagement, and no retention beyond the task. Ask how prohibited data classes are detected, not simply how they are prohibited. Ask what happens when detection fires. A partner who has thought this through will describe a mechanism. One who has not will describe a policy.
Assume you will have to prove it
The last piece is the one most teams skip until they need it.
Purpose limitation tied to the engagement's data processing agreement. No mixing of one client's data with another's, in any artifact or environment. And the ability to state, after the fact, what was handled and that it was not retained.
GDPR Article 5(2) makes the controller responsible for, and able to demonstrate, compliance with the processing principles, and Article 28(3)(h) requires a processor to supply what the controller needs to do so. Under that standard, in a breach investigation, or across a deposition table, "we have a policy" is worth very little. "Here is the record" is worth a great deal. NIST's AI Risk Management Framework (AI 100-1) and ISO/IEC 42001 both exist to give this structure. Ask whether your partner's controls align to either one, and how they would show you.
Most of this can be settled in the contract rather than argued about later, and the language does not need to be elaborate. Four provisions cover the ground.
Name the prohibited data classes explicitly. A general confidentiality clause does not do this work. List the categories that may never enter an AI system regardless of tooling, and make that list specific to your regulatory posture rather than generic.
Require minimization for design work. Synthetic records wherever they are enough. Where a task needs real workforce identity data, name the task, the fields, and the end point in writing. Consumer records and the prohibited classes stay out regardless.
Prohibit automated write paths into your environment. State plainly that artifacts are delivered for human review and ported through your own change process.
Require a handling statement at engagement close. What categories of your data were processed, and confirmation that nothing was retained.
None of these are unusual asks, and a partner already working this way will sign them without negotiation. That reaction is itself useful information. If a firm hesitates, we would expect it to be on the fourth one, because a handling statement is the only provision you cannot satisfy after the fact.
The questions, collected
Put these to anyone who touches your identity data:
- Where is your line between workforce identity data and consumer records, and can you state it without checking a document?
- What specifically requires production data rather than synthetic records matching our schema?
- Can your AI tooling authenticate to any of our systems? If so, who owns that identity?
- How are prohibited data classes detected on input, not just prohibited by policy?
- What is retained after an engagement ends, and how would you prove it?
- Is our data ever processed alongside another client's, in any environment or artifact?
- Which AI governance framework do your controls align to, and how would you show us?
- If we prohibit AI-assisted work entirely on this engagement, what is your process for honoring that?
Now the uncomfortable part. Ask the same eight questions of your own internal teams.
Many organizations pressing their vendors on AI hygiene have developers, analysts, and identity engineers on staff working with considerably less structure than the consultants they are screening. The standard you are about to hold your partners to is the one you will need to meet yourself.
That is the real opportunity here. Teams that answer these eight questions well end up with something more valuable than an AI policy. They end up understanding where their identity data actually lives, who touches it, and what happens to it. That clarity is what makes an identity program last, with or without AI in the picture.