Frequently asked questions

§1 · Compliance

Why check for legal compliance?

Why should a software team care about AI, scraping, privacy, cybersecurity, age-gating, and news-aggregation law?

Because the rules are being written now, in many jurisdictions at once, and they do not agree with each other. Training data that is lawful in one country is an infringement in the next, opt-out signals carry different weight in different places, and compliance dates keep moving. Obligations attach to what an app does (training on scraped material, generating content, making decisions about people) and to the places it reaches, so a team that never thinks about the law is still making legal choices. It is just making them by accident.

What can happen if we get it wrong?

It depends on the jurisdiction and the rule. The heavier regimes carry administrative fines that scale with global revenue; others expose you to private lawsuits, injunctions, or orders to change the product, and a training-data problem can mean retraining or withdrawing a model rather than patching a bug. The quieter costs usually arrive first: a launch blocked in one market, an enterprise deal stalled in security review, a feature rebuilt late because a disclosure or an opt-out check was never designed in. Most of this is cheap to avoid at design time and expensive to fix after.

For the evidence rather than the summary, see Is the legal risk real? For enforcement against software features in particular, with the primary source beside every figure, see Does legal action really happen?

We are a small team with no legal department. Is this really for us?

Yes. Most AI, scraping, privacy, cybersecurity, age-gating, and news-aggregation obligations scale with what the software does, not with headcount. Some laws carve out small businesses; many do not, and the ones developers hit most often (training data, disclosure, crawling) generally apply from the first user. A small team is also the least able to absorb a compliance surprise, which is why catching the basics while the code is still cheap to change matters more for a startup, not less.

We have a legal department, but nobody in it does software law. Is this for us?

Yes, and it may be the case LexLint helps most. Most legal departments are general counsel's offices: contracts, employment, corporate, and a technology question when one arrives. LexLint gives that office a map it has not had: which instruments attach to what an app does and where it operates, each with a plain reading, a citation, and the date it was last checked against its sources, and a clear line that a finding is where a conversation with counsel in that jurisdiction begins rather than a substitute for one. There is a page written for that reader: LexLint for legal teams.

§2 · Applicability

Do these laws apply to my application?

How do I work out which jurisdictions' laws apply?

Applicability depends on several independent angles, and tripping any one of them is enough:

• Where your users are. Most AI regimes reach services offered to people in their territory, regardless of where the company is incorporated or where the servers sit.
• Where you are established. Your home jurisdiction's rules apply to you even for users elsewhere.
• What the app does. High-stakes uses (employment, credit, housing, health, education) carry the strictest duties; consumer-facing chat and generated media trip disclosure and labeling rules; crawling and training trip data and copyright rules.
• Your role in the chain. The developer of a model or system and the deployer of one carry different obligations, and one company is often both.
• Whose data it touches. Data-protection law follows the person the data is about, not the market the app is sold in.

LexLint's lint takes the first and third angles as its input, the jurisdictions you declare and the activities the app performs, and returns what attaches where.

For a longer treatment of the same angles as they fall on an AI agent, the six parties around it and where each one is, start with Introduction: The 6 parties in AI law in the agents section.

I am building an AI agent. Where do I start?

With the agents section: five documents on how the law reaches an agent, written for the people who build and govern one. The first names the parties the law reaches through, the second summarises the AI law in force and the older law that already binds an agent, and the last shows what enforcement has cost, with the sources. A sixth page collects the clocks an incident starts, which is the one to have open when something has gone wrong.

Our app is internal, only for our own employees. Do AI laws still apply?

Often, yes. Employment is one of the most heavily regulated deployment contexts, not a carve-out. The EU AI Act treats AI used in employment and worker management (hiring, task allocation, monitoring, evaluating workers) as high-risk, requires employers to inform workers before such a system is used on them, and bans emotion-recognition systems in the workplace, with only narrow medical and safety exceptions. Several US states and cities regulate AI used in employment decisions, including decisions about existing employees, not just applicants. And data-protection law applies to employees as data subjects, so an automated decision with significant effects on staff triggers the same rights a consumer would have.

What internal-only use usually does escape is the consumer-protection layer: bot-disclosure and consumer-transaction statutes key off a marketplace relationship that an internal tool does not create.

Where does "internal" end?

At the point the system acts on someone outside the company. An agent whose only human user is an employee stops being internal the moment it sends email to customers, negotiates with vendors, or files paperwork with an agency on that employee's behalf. Disclosure and consent rules can attach at that boundary even though nobody outside the company ever logs in.

We do not crawl anything ourselves. Does scraping law still matter?

It can. If your models are trained on scraped material, or you license datasets built from it, the legality of the original collection and the opt-out status of the sources can follow the data downstream. In the EU, a machine-readable rights reservation limits text-and-data mining however the material was gathered (the LexLint note on DSM Directive Article 4 covers this), and providers of general-purpose models owe transparency about training data in some regimes. "We bought it" is a contract answer, not always a copyright answer.

Our app records voices or scans faces. Is that AI law or privacy law?

Usually privacy law, and usually sooner than you expect. The duty attaches to the data rather than to the technology, so a voice or a face can be regulated whether or not a model ever touches it: transcribing a support call, matching a face at a door, or storing a voiceprint to recognize a returning caller can all land inside a biometric statute while nothing about the system is AI at all.

Declare processes_voice or processes_biometrics and the lint returns the instruments that attach. In Illinois that is the Biometric Information Privacy Act, which is worth reading before the others because it carries a private right of action: the person whose voiceprint you took can sue you directly, without a regulator deciding to act first. Texas reaches the same conduct through its Capture or Use of Biometric Identifier Act, Washington through its biometric privacy law, and Colorado through its privacy of biometric identifiers act. Outside the US the route is the sensitive-category rule inside the general regime: Article 9 of the GDPR in the EU, Article 28 of the Personal Information Protection Law in China, and the equivalent provision of the Personal Information Protection Act in South Korea.

Consent is the usual trigger, and the shape of it varies: written notice before collection in some places, a separate opt-in in others, plus retention and destruction schedules that outlive the feature that collected the data. Those are cheap to design in and expensive to retrofit, which is the whole reason to ask the question at lint time.

Teenagers use our app, or we show other people's headlines. Does the lint cover that?

Both, and neither is AI law. Age assurance binds on what the service is and who reaches it: a design code can apply to a general-purpose app simply because children are likely to find it, whichever audience it was built for. News aggregation binds on reproducing, framing, or linking somebody else's journalism, and a two-line snippet can be enough.

Declare serves_minors, operates_social_platform, publishes_adult_content, operates_app_store or ships_mobile_app and the lint returns the age instruments that attach. Declare aggregates_content for the news ones. Nearly every mobile app is shipped through somebody's store, so ships_mobile_app is worth declaring even when running a store is somebody else's business.

Does LexLint cover privacy law? What about cybersecurity?

Privacy, yes, since August 2026: the lint returns personal-data and biometric instruments alongside the AI ones. Privacy law is researched jurisdiction by jurisdiction rather than everywhere at once. A jurisdiction with no research at all warns rather than passing quietly, and so does a jurisdiction covered on other topics but not yet on this one: the lint names the topic it has not researched there. The law page shows which jurisdictions each topic covers. Breach-notification duties that attach to personal data are part of it, and the reporting clocks they start, beside the cybersecurity ones, are collected on one page: The clocks an incident starts.

Cybersecurity, yes, since September 2026, and it is filling quickly. Product-security and cyber-resilience law is its own topic. The EU Cyber Resilience Act and the second Network and Information Security Directive are in the corpus, along with the member-state transpositions, which are read one country at a time because they genuinely differ: some have transposed, some have not and their first-directive rules still bind, and some have transposed and repealed. The state laws in the United States that require reasonable security and the United Kingdom's product-security statute are landing on the same waves.

The Act binds the manufacturer of a product with digital elements, so distributes_software_product is the declaration that carries it for a desktop application, a library, a package, a command-line tool, firmware, or a server somebody else self-hosts; the Directive's duties reach an essential or important entity, declared as operates_essential_service, and a social platform in the EU. Five such roles sit beside the activities (healthcare, finance, essential services, a listed company, telecommunications), because a sector-gated statute binds who you are rather than what the software does. A service with no software anyone else runs is outside the Act's reach rather than missing from the corpus. A breach-notification duty that attaches to personal data stays inside privacy; a duty about the product's own security, or a vulnerability in it, sits here.

Coverage is a fact you can check rather than a claim to take from us. The law page counts what is researched per jurisdiction at each build, the map draws the same thing, and the areas the corpus does not track at all are listed on the legal teams page. Until a jurisdiction is researched on this topic the lint returns a warning for it there, saying cybersecurity law has not been researched, rather than returning nothing.

§3 · Using LexLint

How to use LexLint

How do I run my first lint?

In Claude Code, install the plugin and type /lexlint:

There is no config to write. If the repository has no lexlint.yml yet, the skill asks what the app does and where it will operate, writes the manifest from your answers, and lints against it.

On Claude Code for the web there is no terminal to type that command into, so the repository carries the install instead: a committed .claude/settings.json naming the marketplace, plus the LexLint server's host added to the cloud environment's allowed domains. The documentation has both.

Every other agent connects to the same MCP server at https://mcp.lexlint.io/mcp: Codex or any MCP-compatible agent (the documentation has the config), or call the tools by hand in the browser console. Your agent declares an app profile, the activities the app performs and the jurisdictions it will operate in, and run_lint returns findings. The example walks through a full run, from profile to shipped diffs.

What do I need before I start?

Nothing to arrange first. There is no LexLint account, no configuration file to write, and no key to go and fetch before you begin: install the plugin, type /lexlint, and answer the questions the skill asks about your app.

Access is settled inside the session, at the point the lint needs it. LexLint reads the law through the UnGovr Open Data API, so a run has to identify itself, and the first call that cannot offers your agent both ways to fix that: sign in to a free UnGovr account, or take a trial key with no account, no email and no sign-in. The trial expires and has a lifetime allowance; the account key has neither, which is the whole difference between them. Either way, you keep the key, your agent uses it, and LexLint never stores it. In Claude Code the key is saved to your environment, which a session reads when it starts, so once you have one you open a new session and type /lexlint again. What a key is and what it costs is described in full on the UnGovr key page.

What does LexLint see of my code?

Nothing. The lint takes a declaration, not a repository: two lists, the activities your app performs and the jurisdictions it operates in, both from the lexlint.yml your agent writes with you. That is the whole request. run_lint accepts those two lists and no other argument, and set_profile stores nothing at all.

So no source file, database schema, database row, prompt, session transcript, or piece of git history is sent, and findings come back into a file in your own repository.

Which law comes back is decided by a fixed, rule-based match of that declaration against the corpus, never by a model reasoning about the law: the same two lists against the same corpus build at the same instant always give the same findings. Your agent reads your code to decide what to ask you, and the answers you give are the whole input.

One thing leaves, at the close of a run that found anything: the lint's own output. Your agent shows you the exact contents first and uploads on your approval of that call, so the run is kept on the LexLint portal where you can read it again. What goes is the findings and work items against the declaration you wrote, and never your key, source files, prompts, transcripts, or git identity.

None of this is risk-free and we will not claim it is: two lists still describe an app, and they travel with your API key, which passes through to the data API and is never written down. What LexLint keeps is set out in full on the about page.

What does a finding look like?

A severity, a jurisdiction, a one-line message, a citation, and an as-of date. Findings that concern an instrument LexLint keeps a note on link to that note, a page you can hand to counsel. And the passing state is deliberate: "no basic issues found," never "compliant."

What are the citations for, if I am not a lawyer?

They are for your lawyer, and nobody expects you to parse one. Wherever a finding has a LexLint law note the citation links to it, and the note is the bridge: what the instrument is, when it took or takes effect, what it asks of an app, and where the research was read from, in plain language. When you hand a finding to counsel, hand the citation and the as-of date with it; that is the pair a lawyer needs to check it.

Can I keep a run, or send it to my lawyer?

Yes, and both are things you see before they happen. A run that found anything closes by uploading itself to the LexLint portal, kept against your UnGovr account under a project you name, where each run keeps its findings, its declaration and its dates. Your agent shows you exactly what would leave the repository and uploads on your approval of that call, so a declined approval means nothing was sent.

From there a run exports as a brief written for counsel, with each finding under the law it comes from and the code your developers recorded against it, and it can be shared by a link that works without an account and expires. Deleting a run removes it, and deleting a project removes everything under it. The page written for counsel says what arrives that way, and what the tool will never claim.

§4 · Pricing

What does LexLint cost?

Is LexLint free?

Yes. LexLint is in beta and free to use: no LexLint account, no card, and no billing at the LexLint layer.

Is there anything I have to sign up for?

Not to run a lint. The law underneath is served by the UnGovr Open Data API, which meters usage against a key, and a run gets one the way the section above describes: a free account, or a trial with no account at all. LexLint adds nothing on top of that meter. A call costs exactly what the same call to the data API would cost directly, which for a free key is nothing, and the key page is the authority on allowances.

An account buys two things beyond a key that does not expire: somewhere to keep a run, and a way to send one to your lawyer. Both are described under keeping a run, and neither is needed to lint.

§5 · Accuracy

Legal accuracy

Is LexLint a legal authority?

No, and it must not be used as one. LexLint is a lint: its findings are research summaries of public legal sources, written to catch basic issues early in development. They are not legal advice, they create no attorney-client relationship, they certify nothing, and no LexLint output should be the basis for a legal decision, a filing, or a representation to anyone else. Where a decision matters, a finding is the start of a conversation with qualified counsel in the relevant jurisdiction, never the end of one.

Much of this law is new and unsettled. How much can a lint tell me?

Less than it can tell you about a settled area, and it says so. A lint can tell you which instruments attach to what your app does and where it operates, which of them are in force and which are pending, and where a jurisdiction's law is unsettled; those are facts about published law. What it cannot do is interpret: whether a duty reaches this product, whether an activity is permitted at all, what a restrictive or unsettled posture means for your launch. Findings of that shape are routed to counsel by the lint procedure rather than answered, and an unsettled posture is reported as unsettled, never as permission. Where a decision rides on interpretation, the finding is the start of the conversation with a lawyer, and the citation and date are what you bring to it.

How current and how complete is the data?

Three separate things, and it is worth keeping them apart. The legal news wire is swept every day across every jurisdiction we track, and a story that outruns what we hold opens a research request. The corpus is rebuilt and republished every day, so what the tool reads is what the database says within a day. And every law carries the date it was last checked against its sources, which is the date a finding reports.

What does not happen daily is the research. People do that, in waves, so some laws were reviewed this month and some four months ago. The footer of every page carries the range, oldest date included, and check_access returns the same pair, so you never have to take a single flattering figure on trust. A finding whose entry is older than the corpus's 30-day review window comes back flagged stale.

Completeness is bounded by design. LexLint lints the basics the way a code linter catches common mistakes: a clean run means no basic issues were found, not that no law applies.

I think a finding is wrong. What should I do?

Two things, in this order. If a decision rides on it, take the finding, its citation, and its as-of date to an attorney licensed in that jurisdiction; a disagreement between a lint and a lawyer is resolved by the lawyer. And tell us either way, at lexlint-feedback@ungovr.org. If you signed in to an account rather than taking a trial key, /lexlint-feedback in Claude Code sends the same thing from inside the session, showing you the exact text first. A trial key has no account for a reply to reach, so from one of those, use the address.

That address is read by software as well as by people, so what you put in it decides how fast it moves. A report that carries the law note's link, the one a finding's citation points at, is filed automatically as a re-check against that law and joins the research queue. A report that names nothing we can resolve waits for a person to read it. So paste the link, say what you believe is wrong, and name the source that shows it. We re-check the entry against its primary sources either way; a correction is the single most useful thing anyone sends us.