AI legislation tracker, US privacy law tracker, cybersecurity policy tracker: three scopes, not one
Artificial intelligence legislation, state privacy law and statutory security duties are drafted in the same bills and create different obligations. Why a single technology policy tracker produces a feed nobody reads, and what each scope has to catch on its own.
Artificial intelligence legislation, state privacy law and statutory security duties are three of the most searched subjects in legislative tracking, and they are routinely bundled into one heading. Vendors sell a technology policy feed. Teams set up one saved search with a dozen keywords in it. Both produce a list that is technically correct and operationally useless.
The reason is that the three subjects overlap in how they are drafted and diverge in what they require. They arrive in the same bills. They create obligations for different people, on different clocks, with different consequences for missing them.
Three subjects a drafter mixes and a duty separates
Start from what each one actually asks of an organisation.
Artificial intelligence provisions ask you to characterise a system and then do something about that characterisation: assess it, document it, disclose that it is in use, allow a human review, or not use it for a listed purpose. The work lands on whoever owns the system, and the trigger is deployment.
Privacy provisions grant rights to individuals and impose conditions on processing. The work lands on a privacy function and on contracts, and the trigger is usually a threshold: revenue, record count, or the category of data involved.
Security provisions impose a program and a deadline. Maintain reasonable security, and report an incident within a stated number of hours to a stated recipient. The work lands on security and incident response, and the trigger is an event that has already happened.
An organisation that reads all three out of one list has to re-sort the list every time, by hand, before anything can be routed. That re-sorting is the job the tracker was supposed to do.
One bill, three obligations
The overlap is not theoretical. A single act regulating automated tools in hiring can plausibly contain all of the following:
- An impact assessment requirement for the tool, retained for a period of years. That is an AI duty.
- A candidate notice requirement, plus a right to request the data used about them. That is a privacy duty.
- A requirement to protect the assessment records, and to notify the attorney general within a fixed window if they are exposed. That is a security duty.
Three owners, three clocks, one bill number. Whichever practice area the bill gets filed under in a combined feed, the other two obligations travel with it invisibly, and the people responsible for them find out later.
This is also why bill-level tagging is weaker than it looks. The unit that matters is the provision, not the bill, and a tracker that assigns one subject per bill is making a lossy choice on every bill of this shape.
The same problem runs the other way through omnibus legislation. A significant AI or security provision is often not in an AI or security bill at all. It is a section of an appropriations act or an amendment to an existing consumer protection statute, and anything matching on bill titles will not see it.
The scopes are not the same size, and the tables say so
Published here are two of the three scopes, generated from the corpus when this page is served rather than written down once. Compare the jurisdiction counts as well as the totals, because the second number is the one that tells you how a scope behaves.
| Rank | Jurisdiction | Bills matched | Share |
|---|---|---|---|
| 1 | New Jersey | 35 | 7.3% |
| 2 | Massachusetts | 33 | 6.9% |
| 3 | Virginia | 31 | 6.4% |
| 4 | Illinois | 30 | 6.2% |
| 5 | Connecticut | 26 | 5.4% |
| 6 | New York | 25 | 5.2% |
| 7 | Montana | 24 | 5.0% |
| 8 | Pennsylvania | 24 | 5.0% |
| 9 | Minnesota | 23 | 4.8% |
| 10 | California | 22 | 4.6% |
| 11 | Vermont | 14 | 2.9% |
| 12 | Hawaii | 13 | 2.7% |
| 13 | Rhode Island | 12 | 2.5% |
| 14 | Maryland | 10 | 2.1% |
| 15 | Iowa | 9 | 1.9% |
| 35 further jurisdictions | 150 | 31.2% |
New Jersey leads with 35 matched bills, ahead of Massachusetts (33) and Virginia (31).
| Rank | Jurisdiction | Bills matched | Share |
|---|---|---|---|
| 1 | New Jersey | 20 | 13.3% |
| 2 | Maryland | 15 | 10.0% |
| 3 | New York | 14 | 9.3% |
| 4 | Texas | 10 | 6.7% |
| 5 | Florida | 9 | 6.0% |
| 6 | Minnesota | 8 | 5.3% |
| 7 | Massachusetts | 7 | 4.7% |
| 8 | Michigan | 6 | 4.0% |
| 9 | Illinois | 5 | 3.3% |
| 10 | Oklahoma | 5 | 3.3% |
| 11 | Rhode Island | 5 | 3.3% |
| 12 | Connecticut | 4 | 2.7% |
| 13 | Pennsylvania | 4 | 2.7% |
| 14 | California | 3 | 2.0% |
| 15 | Nebraska | 3 | 2.0% |
| 22 further jurisdictions | 32 | 21.3% |
New Jersey leads with 20 matched bills, ahead of Maryland (15) and New York (14).
For the third, the live per-state count of artificial intelligence bills carries the same table for AI legislation with a fuller explanation of what a count like this does and does not measure.
Read side by side, the tables make a point that no coverage claim does. These scopes differ in both volume and reach, and a tracker tuned for the busiest of them will behave badly on the quietest. In a high-volume area the problem is triage, and the risk is that a significant bill is buried. In a low-volume area the problem is recall, and the risk is that a whole jurisdiction looks quiet when the scope simply failed to match anything there. Those need opposite tuning, which is the practical argument against one combined scope reduced to one threshold.
Both tables are introductions rather than enactments, and the ranking moves with session calendars rather than with policy interest, so a count taken in September and one taken the following March are not comparable. Each table states the date it was taken for that reason.
What an AI legislation tracker has to catch
Vocabulary is the whole difficulty. Bills governing the same conduct are drafted around artificial intelligence, automated decision system, algorithmic discrimination, automated employment decision tool, generative artificial intelligence, digital replica, or a defined term the act invents and then uses throughout. No keyword list survives contact with that, and the list gets worse over time as drafting conventions shift.
Matching on substance rather than on phrasing is the only approach that holds up, which means scoring bill text against a written description of the subject rather than against terms. Our walkthrough of tracking state AI legislation covers how to set that up, and the deeper treatment of AI bill alert systems covers what to do with the output once the matching works.
Two scope decisions are worth making explicitly rather than by default. Whether government procurement and government use of AI belong in your scope, since they are a large share of filed bills and irrelevant to most private organisations. And whether sector-specific AI provisions, in insurance or clinical decision support, belong in the AI scope or in the sector’s own. There is no universal right answer, but an unstated answer produces a feed that quietly drifts.
The AI legislation Tracker is free to browse if you want to see one written scope applied to a real corpus.
What a US privacy law tracker has to catch
The comprehensive state privacy acts are the visible part and the easy part. There are few enough of them to maintain by hand, and every practitioner already knows the list.
The volume is everywhere else: biometric identifier rules, data broker registration and deletion regimes, breach notification amendments that change a deadline or a recipient, health and genetic data protections operating outside HIPAA, and childrens and teen data provisions that increasingly arrive as their own bills. A tracker that only watches comprehensive acts will report a quiet year in a state that amended three statutes.
The part that most affects a practical answer is the exemption language. Entity-level exemptions, data-level exemptions, employee and business-to-business carve-outs and their sunset dates decide who is actually covered, and they are amended far more often than the headline frameworks are passed. Anyone advising on applicability is tracking amendments to exemptions as closely as new acts, and that is a materially different watch list.
The data privacy Tracker is the scope behind the first table above.
What a cybersecurity policy tracker has to catch
Security legislation is the narrowest of the three scopes and the most easily lost inside the other two, because a keyword rule built for privacy catches the breach notification provisions and nothing else.
The distinct surface is security duties written into statute rather than rights granted to individuals:
- Incident reporting deadlines, and the event that starts the clock, which is often discovery rather than occurrence and is where most compliance failures originate.
- Written information security program requirements, and whether the statute names a standard or leaves reasonableness undefined.
- Ransomware payment restrictions and reporting, which apply to public entities in several states and to contractors through them.
- Critical infrastructure definitions, which decide scope for utility, health and transport operators and rarely mention personal data at all.
- Vendor and third-party diligence duties, which travel down a supply chain into organisations the statute never names.
That last category is the strongest argument for a separate scope. A bill imposing duties on operators of a defined class of infrastructure is invisible to a privacy-shaped filter, and it can still be the bill that changes what your client has to do.
The cybersecurity Tracker is the scope behind the second table.
A test that exposes a vendor’s scope boundary
Coverage claims are hard to falsify in a demo, but scope boundaries are not. Three questions do most of the work, and they are quick.
Name a bill you deliberately excluded, and say why. Any scope worth trusting has edges, and a vendor who has thought about theirs can produce an exclusion in seconds. A vendor who cannot has a keyword list.
Show me a bill that appears in more than one of your scopes. If nothing ever appears twice, the scopes are partitioned by assignment rather than by substance, and the multi-obligation bills described above are being filed under one heading and lost to the other two.
How would I find out you had missed something? The failure mode in this category is silence. A scope that matches nothing in a state, and a state with no relevant activity, look identical from the outside. Ask what distinguishes them on the vendor’s side, and treat a confident “that does not happen” as a worse answer than an honest account of the monitoring.
Downstream of all three subjects there is a rulemaking layer that the legislative scope does not reach, since a statute frequently delegates the operative detail to an agency. Our guide to regulatory enforcement signal tracking covers that boundary, and Regulatory Watch is the Federal Register only, permanently, which is a limit rather than a roadmap item.
Running three scopes without reading three feeds
The argument for separate scopes is about matching and routing, not about how many things land on your desk. Separate scopes are what let a bill reach three owners; they are not a reason to subscribe to three feeds and read all of them.
That is the split LawSignals runs. Each practice area is its own Tracker with its own written scope over one shared corpus, so a bill can match more than one, and the monthly deliverable is a written issue per practice area rather than a merged digest. The scopes themselves are model-drafted and validated by retrieval measurement rather than attorney-reviewed, which makes them a research and drafting input to your own judgement, and the methodology page publishes per-state corpus quality instead of a single coverage figure, because those numbers are not uniform and smoothing them would be the more comfortable lie.
Past issues are open to read without an account in the report archive, which is a better test of whether any of this is useful than a feature list. The full set of practice areas is on the Trackers directory.
