Every AI system runs on regulated data.

AI is a data-privacy problem before it is anything else

It is easy to think of AI risk as being about outputs — a biased decision, a hallucinated statement, a synthetic likeness. But underneath every AI system is data: the data it was trained on, the data you feed it, the data it generates, and the data it stores. Each of those is potentially regulated, and the obligations attach whether or not anyone thought about privacy when the tool was adopted. An organization that deploys AI without mapping its data flows is making compliance decisions by accident. The first real step in AI privacy work is unglamorous and essential: understanding what data the AI actually touches, where it comes from, where it goes, and which laws govern it.

The Illinois and multi-state privacy landscape

Illinois sits at the center of several overlapping regimes. BIPA governs biometric identifiers and remains a high-exposure privacy statute, with its own consent and retention rules (covered in depth on the BIPA page). The state has also moved to regulate specific high-risk AI uses directly: the Wellness and Oversight for Psychological Resources Act, enacted in August 2025, restricts the use of AI in therapy and psychotherapy — it bars AI from making independent therapeutic decisions or directly interacting with clients in therapeutic communication, and it requires licensed-professional review and approval before AI-generated therapeutic recommendations or treatment plans are used. It is not a general data-privacy statute, but it signals that Illinois will legislate against particular AI uses, and it frequently overlaps with privacy, confidentiality, and governance concerns. Employment-related AI carries its own data and notice obligations under HB 3773. Beyond Illinois, organizations with customers or operations elsewhere face a growing patchwork: California's privacy regulations now reach automated decision-making technology, with among the most stringent such consumer-rights obligations in the country phasing in over time; Colorado has moved to a narrower automated-decision disclosure framework with obligations scheduled to begin in the future; and organizations with European users confront the GDPR and the EU AI Act, whose phased obligations must be checked against the current official text. As a practical risk posture, an organization whose AI touches data across several states often evaluates whether to align controls to the most demanding standard in its realistic footprint rather than the Illinois minimum, recognizing that which jurisdiction's law governs is a fact-specific question. The exact reach of each of these should be verified, because the landscape is still forming.

Training data, prompts, and outputs each carry risk

AI privacy risk is not one thing; it lives at three distinct layers. Training data raises questions of provenance and rights — what was the model trained on, and was that data used lawfully. Input data is the information your organization or its users feed the system, which can include personal, confidential, or regulated data that may end up improving a vendor's model or leaving your control. Output data — what the system produces — can itself contain or reconstruct personal information, or create new regulated data like a biometric template or a digital likeness. A privacy analysis that looks only at one layer misses the others, and the vendor contract behind the tool often determines how each layer is actually handled.

An analysis grounded in how the systems work

Mapping AI data flows accurately requires understanding how these systems ingest, process, and emit data — which is exactly the operational knowledge Adam brings as the architect of a production AI system who governs it daily and holds the AIGP credential. The privacy questions that matter most — does this tool create biometric data, does our input train the vendor's model, does the output reconstruct personal information — are answered by understanding the technology, not just reading a privacy policy. This is also where AI privacy work connects to vendor-contract review, BIPA compliance, and the overall governance framework: they are facets of the same underlying question of how data moves through the system.

Building a defensible privacy posture

The deliverable work is a data-flow map of the organization's AI use, an assessment of which laws govern each touchpoint, remediation where consent or handling is deficient, and privacy terms built into the AI vendor relationships going forward. For organizations in regulated sectors or with multi-state or international exposure, the analysis extends to the specific regimes they face — and where applying another jurisdiction's privacy law requires it, the firm coordinates with local counsel admitted there and with sector or IP specialists rather than reaching beyond where it is authorized to practice. The firm leads this hourly, on a governance retainer, or as a defined privacy assessment — with current verification of the fast-moving statutes built into the work rather than assumed.

What usually goes wrong

The most common failure is adopting an AI tool with no understanding of what data it touches — so personal, biometric, or confidential data flows into and out of a system nobody evaluated for privacy, and the obligations are being violated invisibly. A close second is the input-data leak: employees or systems feeding personal or confidential data into an AI tool whose contract lets the vendor use it to train their models, surrendering control of regulated data without anyone deciding to. The third is treating privacy as a static, one-time policy while the AI footprint and the law both expand — so a posture that was defensible when adopted quietly falls out of compliance.

Related

• BIPA Compliance →
• AI Vendor & Procurement Contract Review →
• AI Governance Frameworks & Policy →