Here’s a pattern I’ve seen more than once. Finance starts an AI pilot to speed up part of the month-end close, perhaps matching invoices or drafting reconciliation notes. It works well. A few weeks in, internal audit hears about it and asks a reasonable question: how does this fit into our controls over financial reporting? Nobody has an answer, and the pilot is paused while everyone works one out.
The pilot wasn’t the problem. The timing of the question was. SOX compliance, privacy laws, sector rules, and new AI-specific regulations can all apply to an AI project, and every one of them is far easier to handle before a pilot touches real data than after. This post covers how to map those obligations up front, in a way a mid-size IT team can actually run.
One note before we start: this is a practitioner’s guide to asking the right questions, not legal advice. Your legal and compliance people, or outside counsel, make the calls. IT’s job is to bring them the facts they need, early.
Why AI pulls obligations into scope
AI projects trigger obligations in four ways. They touch data that laws already govern. They can become part of a control, such as a review step in a financial process. They can make or influence decisions about people. And AI vendors usually process your data, which makes them subject to your contracts and your regulators’ expectations.
Here’s how the assessment asks the question, and the 0 to 4 ladder I score it against:
G3. How have you addressed the AI regulations and standards that apply to you?
- Not considered
- Aware, but not assessed
- Legal or compliance consulted on specific projects
- Applicable requirements mapped (e.g., EU AI Act, state AI laws, industry rules)
- A formal framework adopted (e.g., NIST AI RMF or ISO/IEC 42001) with regular reviews
Level 2 is common and reactive: legal gets consulted when someone thinks to ask. Level 3 means you’ve mapped what applies before projects start, so nobody has to remember to ask.
The four families of obligations to check
1. Financial controls
For U.S. public companies, Sarbanes-Oxley Section 404 requires management to assess internal control over financial reporting. If an AI tool touches a process that feeds the financial statements, such as journal entries, reconciliations, or accounts payable, it’s likely in scope. Three questions matter most:
- Is AI output reviewed by a person before it affects the books, and can you show evidence of that review?
- Is the AI tool covered by your IT general controls, including access management, change management, and operations?
- Are changes to prompts and configurations controlled like other changes? If someone can change how the AI behaves without review, that’s a change management gap. Keeping configurations in version control, as covered in observability for AI, closes it.
Private companies aren’t subject to SOX, but lenders, investors, and auditors often expect similar controls. The same questions are worth asking.
2. Privacy
If personal data goes into an AI tool, your privacy obligations follow it. A growing number of U.S. states have comprehensive consumer privacy laws, and if you handle data about people in the EU, GDPR applies. The questions to ask: is using the data for this purpose consistent with what people were told? Is the minimum necessary data being used? Is there a data processing agreement with the vendor? Can you honor access and deletion requests for data inside the AI tool? And does the use involve profiling or automated decisions about people, which several privacy laws treat with extra care?
3. Sector rules
Industry regulations apply to AI the same way they apply to any system. Health data covered by HIPAA requires a business associate agreement with any vendor that handles it, AI vendors included. Financial institutions have safeguards obligations for customer information. Education records have their own protections. The industry-specific posts in this series, such as AI readiness in healthcare IT and AI readiness for financial services, cover these in more depth.
4. AI-specific laws
This is the fastest-moving area. The EU AI Act sets obligations based on risk level for organizations that place AI systems on the EU market or whose AI output is used there, and it’s being phased in over several years. In the U.S., states and cities have passed rules aimed at specific uses, particularly AI in employment decisions; New York City, for example, requires bias audits for automated employment decision tools. Because this area changes so often, the most important step is to assign someone to track it.
The asset: a ten-question pre-pilot screen
Run every proposed pilot through these questions before it uses real data. Most take seconds to answer.
- Does it touch data or processes that feed the financial statements?
- Will its output be used in a financial process without human review?
- Does it process personal data? Whose: employees, customers, or consumers, and in which states or countries?
- Does it process health, financial account, or student data?
- Will it make or support decisions about individuals, such as hiring, credit, eligibility, or pricing?
- Is the vendor processing our data, and is a data processing agreement or business associate agreement in place?
- Can we find and delete a specific person’s data inside the tool if asked?
- Is the use customer-facing, and does it need disclosure?
- Will the output be used in the EU?
- Who in legal or compliance has reviewed it, and when?
The decision rule: a yes to question 1, 2, or 5 means legal or compliance review and a documented control before the pilot uses real data. Other yes answers go to the relevant owner for a check. If you have an AI council, make this screen part of its intake form.
Turning screens into a map
Level 3 is a standing map rather than a per-project screen. For each AI tool and use case in your AI inventory, record the data categories involved, where the data subjects are, which of the four families apply, the specific obligations, the control that meets each one, the owner, and where the evidence lives. Review it when new tools arrive and at least twice a year.
Level 4: adopt a framework
Two frameworks come up most often. The NIST AI Risk Management Framework is voluntary and free, and organizes AI risk work into four functions: Govern, Map, Measure, and Manage. It fits mid-size organizations well because you can adopt it gradually. ISO/IEC 42001 is a certifiable standard for an AI management system; it’s more demanding, and it’s most useful when customers or partners ask for certification. For most mid-size teams, starting with the NIST framework and considering ISO/IEC 42001 later is the practical order. How either fits into your broader governance is covered in AI governance for mid-size IT.
Mistakes I see at this stage
“It’s just a pilot.” A pilot using real data carries the same obligations as production. Pilots with synthetic or public data are the exception.
Leaving it all to legal. Legal can’t assess what it can’t see. IT has to supply the data flows, the vendors, and the access details.
Treating a vendor’s compliance claims as your own. A vendor being compliant doesn’t make your use of it compliant. You still own the purpose, the data, and the controls.
Nobody tracking new laws. AI rules are changing too quickly for an annual check. Assign an owner.
Where does your team actually stand?
Regulatory mapping is one of 24 questions in the AI Readiness assessment, which covers six dimensions: data, security, infrastructure, skills, use cases, and governance. The free version is 10 questions and gives you a score in a few minutes.
Get your free AI Readiness Score →
Want to see what the full assessment covers first? Flip through a complete 38-page sample report.
Related guides
- Observability for AI: Logging What Your Assistants Do
- AI Readiness in Healthcare IT: HIPAA Changes the Order of Operations
- AI Readiness for Financial Services IT: Regulators Are Already Asking
- The 30-Minute AI Council: Lightweight Governance That Sticks
- Build Your AI Inventory in Two Weeks (Auditors Will Ask)
Frequently asked questions
Does SOX apply to AI tools?
It can. For U.S. public companies, if an AI tool touches a process that feeds the financial statements, it's likely within internal control over financial reporting. Expect questions about human review of AI output, IT general controls, and change management for prompts and configurations. Your compliance team makes the call.
Do privacy laws apply to data used in AI tools?
Yes. Privacy obligations follow personal data into AI tools, covering purpose, data minimization, contracts with processors, access and deletion requests, and, in several laws, profiling or automated decisions about people. Map which laws apply to each use before a pilot uses real data.
What is a pre-pilot regulatory screen?
Ten quick questions run before a pilot touches real data, covering financial processes, personal and sector-regulated data, decisions about individuals, vendor agreements, deletion requests, customer-facing use, EU use, and legal review. A yes on the financial or decisions-about-people questions triggers legal review and a documented control first.
Should a mid-size company adopt NIST AI RMF or ISO/IEC 42001?
For most mid-size organizations, start with the NIST AI Risk Management Framework: it's voluntary, free, organized around Govern, Map, Measure, and Manage, and can be adopted gradually. ISO/IEC 42001 is a certifiable management system standard, most useful when customers ask for certification.




