Is Your Tool Really AI? Why That Definition Drives Your Compliance Plan
Call a tool "AI" and you can sell it. Call it "AI" under the law and you inherit duties. That single label can trigger audits, notices, validation, privacy obligations, and contractual exposure.
Here's the point: you don't need a thesis on machine learning. You need a way to decide, before go-live, whether a tool is regulated, where, and what that means for your program.
The definition problem: tech marketing vs. legal exposure
Teams toss "AI" around to describe everything from generative tools to classic machine learning to newer agentic systems. That's fine for product pages. It's not how laws read.
Most frameworks care about two things: does the tool help make a decision about people, and how much weight does it carry in that decision. The more it "assists" or "facilitates" a consequential call (hire, promotion, pricing, credit, housing, health), the more likely you're in scope.
Federal anchors to keep you grounded
Under Title VII, any selection mechanism can create disparate impact risk. The Uniform Guidelines on Employee Selection Procedures treat "selection procedure" broadly. If a tool ranks, screens, scores, or recommends candidates, expect monitoring and, if impact appears, validation obligations.
Practical takeaway: treat algorithmic screens like any other test. Track outcomes. If you see statistically significant differences, be ready to validate job relatedness and business necessity. See the Uniform Guidelines here: eCFR Part 1607.
State and local patchwork: same concepts, different triggers
New York City's AEDT law pulls you in if a tool is used to help make employment decisions. If you're in scope, you'll need a bias audit, public posting of results, and candidate notices. Details live with the city's consumer protection agency: NYC AEDT.
Colorado frames covered tools as those that "assist" decisions. California's recent regs say "facilitate." Those words sound similar, but they'll matter in complaints, audits, and negotiations. Read definitions against your specific use case and the tool's actual function, not the vendor's pitch.
Privacy adds another filter. The California Consumer Privacy Act applies only if you're a "business" under the statute (doing business in CA, controlling personal information, and meeting a threshold). One threshold is prior-year gross revenue above $26,625,000. If you don't meet the test, the AI-specific duties in that framework might not apply-though other laws could.
Operate globally? The EU AI Act classifies systems by risk and sweeps in many employment uses. Map where your decision impacts occur, not just where your team sits.
Same tool, different hat
A resume screener used for hiring may be regulated. The same core engine used for retail demand forecasting may not be, under employment-focused laws. Don't assume "AI tool" equals the same obligations across contexts.
Also check your contracts. Many service agreements restrict "AI" use or require disclosures, security controls, or opt-outs. Those definitions can be broader than any statute. If you signed it, you own it.
A pre-deployment decision framework that works
- Inventory the use case: decision type, data used, affected people, jurisdictions.
- Classify the tool: generative, ML, agentic, or simple automation. Note how much it influences outcomes and whether humans can override.
- Map laws by context: employment, credit, housing, healthcare, education, consumer. Flag NYC, CO, CA, and any international reach.
- Get the technical story from the vendor: inputs, outputs, model type, training data sources, retraining cadence, explainability, and human-in-the-loop design.
- Bias risk plan: baseline your current process, define metrics, run pre-deployment tests, and schedule ongoing monitoring.
- Validation pathway: if impact appears, line up job analysis, criterion content, and construct validity support.
- Notice and rights: candidate/employee notices, opt-out (if required), appeal or human review routes, and recordkeeping.
- Privacy and security: data minimization, retention, deletion, vendor subprocessors, cross-border transfers, and CCPA/CPRA thresholds.
- Contracts: vendor warranties and cooperation for audits; customer obligations you've agreed to; indemnity and limitation of liability alignment.
- Governance: designate a gatekeeper, require intake approvals, keep an AI inventory, document decisions, and set a monitoring cadence.
Quick calls you'll face (and how to think about them)
- Spreadsheet macro that ranks applicants by keyword match: may be covered as a "selection procedure" federally; check NYC/CO/CA triggers if used in hiring decisions.
- GenAI drafting job ads: usually outside "selection" scope, but still review for discriminatory language, IP, and privacy issues.
- Marketing model predicting product demand: employment-focused AI laws likely don't apply; privacy and sector laws might.
Operational habits that reduce risk
- Centralize intake. No tool goes live without legal review.
- Standardize notices, audit templates, and validation steps.
- Keep humans meaningfully involved, with authority to override.
- Schedule post-deployment reviews tied to version changes, drift indicators, or population shifts.
- Train HR, legal, procurement, and IT on the difference between "cool feature" and "regulated function."
The question isn't "is this AI?" It's "does this trigger duties where we operate, given how we use it?" Answer that before rollout, and you avoid public audits, missed notices, and emergency remediation under pressure.
If your team needs a fast primer on AI concepts to support reviews, see this curated catalog: AI courses by job.
Your membership also unlocks:
