LexLint
Beta
LexLint
Beta
FAQ
The questions developers actually ask about AI and scraping law, and about LexLint itself. Answers here are orientation, not legal advice; the last section says exactly what that means.
§1 · Compliance
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 where it runs, so a team that never thinks about the law is still making legal choices. It is just making them by accident.
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.
Yes. Most AI and scraping 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.
§2 · Applicability
Applicability turns on several independent angles, and tripping any one of them is enough:
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.
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.
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.
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.
§3 · Using LexLint
LexLint is an MCP server at https://mcp.lexlint.org/mcp.
Connect Claude Code, 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 lint_app_profile
returns findings. The
example walks through a full run, from profile to shipped diffs.
One thing: a free UnGovr API key from https://www.ungovr.org/open-data/api-keys, the same key that serves the UnGovr Open Data API. LexLint has no account of its own; your key is passed through on each call and never stored.
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. Two behaviors are deliberate: a jurisdiction LexLint has no current data for comes back as a warning rather than a silent pass, and the passing state is "no basic issues found," never "compliant."
§4 · Pricing
Yes. LexLint is in beta and free to use: no LexLint account, no card, and no billing at the LexLint layer.
Because the data underneath is served by the UnGovr Open Data API, and your key is how that usage is metered. LexLint adds nothing on top: the key passes through, and a call costs exactly what the same call to the data API would cost directly. Free keys and their daily allowance are described on the key page, which is the authority on key tiers.
§5 · Accuracy
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.
Every finding carries its citation and an as-of date, so you can see exactly how fresh the answer is, and the corpus behind it is maintained continuously. Two honesty rules are built in: a jurisdiction without current data warns instead of passing silently, and data that has aged in a fast-moving area is flagged as stale. Completeness is bounded by design. LexLint lints the basics, the way a linter lints syntax and smells, and a clean run means no basic issues were found, not that no law applies.
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: email hello@ungovr.org with the finding, the citation, and what you believe is wrong, and we will re-check the entry against its primary sources. Reports like this are how the corpus gets better, and they are genuinely welcome.