Designing an In-Browser AI Judgment Machine

Full report

On this page

Executive summary

An effective in-browser “Judgment” machine should be built as a jurisdiction-aware legal and ethics triage system for prompts and proposed AI use cases, not as a system that assigns a moral score to the user. That design choice is not just a product preference. It tracks current law and guidance: the EU AI Act expressly prohibits certain forms of social scoring and manipulative AI, while GDPR and UK GDPR rules place extra safeguards on solely automated decisions and profiling that have legal or similarly significant effects on people. A product that says “the AI views you as suspicious/untrustworthy” is therefore much harder to justify than one that says “this request appears prohibited in the EU,” “high-risk in employment contexts,” or “allowed with mitigation if notice, human review, and logging are present.”

For default global coverage, the most valuable starting corpus is a core stack of binding law plus authoritative soft law: the EU AI Act; GDPR Article 22; the Council of Europe Framework Convention on AI; China’s generative-AI and synthetic-content labeling rules; South Korea’s AI Framework Act; Colorado’s 2026 automated decision-making law as the most operational U.S. state model; Canada’s Directive on Automated Decision-Making; and then a layer of global and national governance instruments such as the OECD AI Recommendation, UNESCO’s Recommendation on the Ethics of AI, NIST AI RMF and the NIST Generative AI Profile, Japan’s AI Guidelines for Business, Singapore’s model governance frameworks, Australia’s updated AI adoption guidance, and the UK ICO’s AI/data-protection guidance. That stack gives strong coverage of prohibited uses, high-risk decision contexts, transparency duties, human oversight, recourse, privacy, bias, and governance.

The strongest implementation pattern is a hybrid, offline-first browser architecture. Keep the legal corpus, rule tables, and citations locally in SQLite-Wasm or IndexedDB; add a service worker for offline operation; use a deterministic rule engine first; and add small local classifiers or embedding models only for prompt analysis and retrieval. Browser storage and offline operation are mature enough for this pattern: IndexedDB is built for significant structured client-side data and offline querying, service workers are designed to cache assets and enable offline experiences, OPFS is optimized for high-performance in-place writes, and WebAssembly provides a portable execution target for browser-side databases and inference engines.

The core judgment output should therefore be a layered decision, not a single yes/no. The system should return: a primary label; the affected jurisdictions; the triggering legal criteria; the missing mitigations; a confidence score; machine-readable citations; and a counterfactual explanation describing what changes would move the request from prohibited or risky to allowed-with-mitigation. This aligns with the explainability, transparency, recourse, and human-oversight themes that recur across the EU AI Act, the OECD principles, UNESCO’s recommendation, Canada’s directive, and the UK ICO guidance.

Regulatory baseline and source prioritization

The right way to curate a worldwide offline database is to organize sources by authority first, jurisdiction second, and operational relevance third. In practice, that means the system should rank sources in this order: enacted binding law and treaty text; official regulatory guidance implementing that law; official government policy instruments for public-sector AI use; then widely adopted international frameworks. Where unofficial translations exist, they can be stored as convenience material, but the app should mark them as non-authoritative and keep the primary citation linked to the official source.

For jurisdictions not expressly selected by the user, the most defensible default is a global baseline mode that applies: binding transnational rules where they are directly relevant; the most protective jurisdictional rule among the jurisdictions the product claims to support; and international guidance where hard law is absent. That is especially important because enacted, cross-sector AI statutes remain uneven outside Europe, China, Korea, and a handful of public-sector or subnational frameworks. UNESCO’s observatory and OECD policy work are useful monitoring layers precisely because many countries are still operating through strategies, ethics codes, public-sector rules, or existing privacy/consumer law rather than comprehensive AI statutes.

Judgment model and legal criteria

A browser-native judgment engine should classify the request and deployment scenario, not the user’s worth or character. The clean abstraction is: “What regulated AI activity is this prompt seeking?” rather than “What kind of person is asking?” That distinction matters because the EU AI Act bans certain social-scoring uses and privacy law adds protections around profiling and significant automated judgments. A safe design can still emit a narrow, internal misuse-intent confidence feature for model routing, but it should never be displayed as a social or reputational score about the person.

The most useful label set is five primary labels plus one uncertainty overlay:

The legal criteria should be stored as machine-runnable predicates. Each predicate should capture: scope, affected persons, context, regulated domain, risk type, prohibited conduct, required safeguards, and citation payload. A practical criteria taxonomy is shown below.

When jurisdictions conflict, the engine should show a jurisdiction matrix, not flatten them into one answer. For example, a use case may be “prohibited in the EU,” “regulated in Korea,” and “permitted with guidance-based mitigation in Japan.” If the user provides no jurisdiction and the use case touches rights-sensitive domains such as employment, credit, insurance, healthcare, or public services, the safest default is a most-protective supported-jurisdiction result plus a notice that localized legal advice is still required. That approach is consistent with the risk-based logic shared by EU, OECD, NIST, Australia, Japan, Singapore, and Canada.

Data architecture and reasoning workflow

The legal corpus should be modeled as a portable, versioned knowledge base that can run entirely in the browser. A practical design is a primary relational store persisted locally, surrounded by compact auxiliary indices for lexical retrieval, embeddings, and explainability templates. On modern browsers, both IndexedDB and OPFS-backed databases are viable; OPFS is optimized for higher-performance file access, while IndexedDB is widely available for offline structured storage and indexing.

flowchart LR
    U[User prompt] --> N[Prompt normalizer]
    N --> J[Jurisdiction resolver]
    N --> T[Topic and risk tagger]
    T --> R1[Deterministic rule engine]
    T --> R2[Lexical retriever]
    T --> R3[Embedding retriever]
    J --> KB[Local legal knowledge base]
    R2 --> KB
    R3 --> KB
    R1 --> S[Scenario evaluator]
    KB --> S
    S --> E[Explanation composer]
    E --> O[Judgment UI]
    O --> A[Appeal or human review flow]

A robust minimum schema is:

A useful indexing strategy is hybrid retrieval. The first pass should use deterministic features and lexical search because law is highly phrase-sensitive. The second pass can use embeddings for fuzzy similarity when users describe a scenario indirectly. For offline performance, store: a compact inverted index over normalized keywords and aliases; a full-text or token index over provision summaries; and an optional small embedding index for prompt-to-example matching. This division is well suited to browser capabilities: IndexedDB supports large structured datasets and indexes; SQLite-Wasm and DuckDB-Wasm run locally in WebAssembly; and small transformer-style models can run in-browser, including on WebGPU where available.

An example set of records for the highest-value provisions would look like this:

The reasoning workflow should be explicit and inspectable.

flowchart TD
    A[Normalize prompt] --> B[Detect language and geography]
    B --> C[Extract legal facts]
    C --> D[Match topics and entities]
    D --> E[Retrieve candidate provisions]
    E --> F[Evaluate prohibited-use rules]
    F -->|Hit| G[Return prohibited or disallowed]
    F -->|No hit| H[Evaluate high-risk and transparency duties]
    H --> I[Check mitigations present or missing]
    I --> J[Score confidence]
    J --> K[Compose explanation and citations]
    K --> L[Render result and allow appeal]

A disciplined prompt-analysis pipeline should use these steps:

First, normalize the prompt into a fact schema: action verb, AI capability, target population, domain, stakes, jurisdiction clues, data types, deployment actor, and whether the request is for development, procurement, deployment, or publication. Second, run a rules layer that identifies bright-line triggers such as emotion recognition, social scoring, real-time biometric identification, candidate screening, credit scoring, public-benefit eligibility, deepfake, political persuasion, or law-enforcement profiling. Third, retrieve candidate provisions by keyword and vector similarity. Fourth, apply applicability logic: effective date, territorial scope, sectoral scope, and source authority. Fifth, compute the label. Sixth, generate a confidence score from source authority, specificity of the fact match, and jurisdiction certainty. Seventh, prepare a counterfactual explanation. This sequence maps well onto the NIST AI RMF’s govern-map-measure-manage structure and the explainability/oversight themes in EU, OECD, UNESCO, Singapore, and Canada materials.

A practical confidence model can be expressed as a weighted synthesis:

• Authority score: binding law > official regulator guidance > public-sector policy > international soft law.
• Specificity score: exact bright-line match such as “emotion recognition in workplace” scores much higher than vague similarity to “employee monitoring.”
• Jurisdiction score: explicit jurisdiction or actor context raises confidence; missing geography reduces it.
• Mitigation completeness score: explicit human review, notice, logging, appeal, and labeling increase the probability of “allowed with mitigation” rather than “risky.”
• Novelty penalty: agentic, multimodal, or unusual scenarios without close criterion matches should default toward “uncertain/human review.”

For ambiguous or novel cases, the system should never hallucinate a hard legal conclusion. It should instead say: “No bright-line prohibition matched; closest concerns are X, Y, Z; confidence is low because jurisdiction or deployment context is unclear.” It should then fall back to the global governance layer from OECD, UNESCO, NIST, Singapore, Australia, and Canada. That gives the user a practical answer without pretending a legal certainty that the sources do not support.

Product experience, privacy, and governance controls

The UI should present an interactive judgment card with six visible blocks: label, jurisdiction(s) affected, why this triggered, what would fix it, confidence, and citations. The user should be able to expand the rationale from a one-sentence answer into a structured trace showing matched facts, matched provisions, exceptions considered, and missing mitigations. This aligns well with the transparency and explanation duties reflected in EU Article 50, the UK ICO’s explaining-AI guidance, and Canada’s emphasis on transparency and recourse.

A recommended layout is:

The product should also have an appeal or override flow. A user who disputes a result should be able to: choose or change jurisdiction; supply missing context; indicate whether the use is internal, public, or government-facing; and request human review. The system should then recompute the result and preserve the original and revised traces side by side. This pattern is consistent with the recourse theme in Canada’s directive, the human-review rights in Colorado’s ADMT law, and the broader fairness logic in GDPR/UK GDPR guidance.

Because the user specifically wants a machine that expresses how the AI “views” the prompt, the privacy and consent language must be unusually careful. The product should disclose, in plain language:

That framing is not merely defensive drafting. It is substantively supported by the legal context: the EU prohibits AI social scoring, while GDPR and UK GDPR rules impose extra protection where profiling or automated significant decisions are involved. FTC guidance also cautions that privacy commitments and confidential data promises remain enforceable, even in AI settings.

A strong default compliance and retention policy is:

Implementation options, performance, and roadmap

The best fit stack is an offline-first progressive web app with worker-based storage and inference. Service workers provide caching and offline bootstrapping; IndexedDB or OPFS-backed SQLite provides local persistence; WebAssembly lets the browser run local databases and model runtimes; and ONNX Runtime Web or Transformers.js can handle small classification and embedding tasks locally.

The browser platform supports these choices well. IndexedDB is intended for significant structured client-side data and offline queries; service workers are specifically meant to intercept requests and enable effective offline experiences; OPFS provides high-performance origin-private storage and synchronous access handles in dedicated workers; WebAssembly is a portable compilation target for browser execution; DuckDB-Wasm and SQLite-Wasm run analytical or relational workloads locally; ONNX Runtime Web provides in-browser inference; and Transformers.js supports browser-side model pipelines with optional WebGPU acceleration.

For broad deployment, I would recommend this stack:

• Frontend: React, Svelte, or plain TypeScript PWA.
• Storage: SQLite-Wasm on OPFS where available; IndexedDB fallback.
• Inference: deterministic rule engine first; small ONNX or Transformers.js models for feature extraction and retrieval.
• Runtime isolation: Web Workers for retrieval and inference; service worker for offline assets.
• Update model: signed policy-pack bundles with semantic versioning and differential updates.
• Remote mode: optional, explicit opt-in, zero-retention configuration, and send normalized facts instead of the raw prompt where possible.

Performance estimates depend heavily on corpus size and model choice, but the following are realistic engineering targets for a first serious release. These are implementation estimates rather than published benchmarks:

Those targets are achievable because the browser can store and query sizeable local datasets, cache assets for offline use, and run local Wasm/ONNX workloads. The main limiting factors are storage quotas, model size, WebGPU availability, and device thermal/memory constraints.

A practical roadmap is:

For a focused team, that implies roughly 22–41 weeks to reach a strong, broad-coverage product, with a credible MVP in roughly 9–13 weeks. The timeline is driven less by UI coding than by legal curation, criteria authoring, and validation against edge cases.

Worked judgments, risks, and limitations

The examples below assume global baseline mode with no user-specified jurisdiction. In that mode, the system should show the most restrictive supported jurisdictions and also distinguish between “binding prohibition” and “governance risk.”

Worked judgment for workplace emotion screening

Prompt

“Build an AI that reads applicants’ facial expressions during interviews and automatically rejects low-confidence candidates.”

Recommended judgment

• Primary label: Illegal or prohibited in the EU; disallowed by product policy globally.
• Confidence: High.
• Why: The request explicitly involves emotion inference in a workplace context and automated hiring evaluation. EU Article 5 prohibits using AI to infer emotions in the workplace, except for medical or safety reasons. Separately, Annex III treats recruitment, candidate evaluation, and workplace performance/behavior monitoring as high-risk. Colorado’s ADMT law also treats employment-related consequential decisions as covered. Canada’s public-sector hiring guidance likewise routes AI-supported staffing through the automated-decision framework.

Step-by-step machine trace

Counterfactual explanation

“If you remove emotion inference entirely and instead use AI only to assist with structured scheduling or draft interviewer notes, while keeping a human decision-maker and clear notices, the request could move toward ‘allowed with mitigation.’” That shift aligns with the contrast between prohibited emotion inference and ordinary low-risk or mitigated assistance.

Worked judgment for public-space police facial recognition

Prompt

“Use real-time facial recognition in a public square so police can identify wanted suspects automatically.”

Recommended judgment

• Primary label: Prohibited or extremely restricted in the EU; globally high-risk and rights-sensitive.
• Confidence: High.
• Why: EU Article 5 prohibits real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes except for narrow exceptions tied to victims, imminent threats, or serious crimes, plus strict authorization and safeguards. Biometrics are also listed in Annex III as high-risk AI.

Step-by-step machine trace

Counterfactual explanation

“If the use case were a non-public, voluntary identity verification flow for a named user proving they are who they claim to be, the legal posture would be materially different from real-time public-space police identification.” That distinction appears directly in Annex III’s carve-out for biometric verification used solely to confirm a claimed identity.

Worked judgment for undisclosed deepfake political content

Prompt

“Generate a video of a candidate saying something they never said, and make it realistic enough that people won’t know it’s AI.”

Recommended judgment

• Primary label: Disallowed by product policy; likely unlawful or non-compliant in multiple jurisdictions.
• Confidence: High.
• Why: The prompt explicitly seeks deceptive synthetic content and concealment. EU transparency rules require AI-generated or manipulated content to be marked and deepfakes to be disclosed once Article 50 applies from 2 August 2026. The EU also classifies certain AI systems intended to influence voting behavior as high-risk. China now requires labeling of AI-generated synthetic content, including detection and explicit indication regimes. FTC materials also make clear that deceptive AI-generated content and false claims can trigger enforcement, and the agency has acted against AI-enabled deception.

Step-by-step machine trace

Counterfactual explanation

“A clearly labeled fictional or satirical example that does not mislead viewers about the real person could be treated differently, though local election and defamation laws would still need review.” The key distinction is disclosure and non-deceptive presentation.

Worked judgment for customer-support copilot

Prompt

“Use an LLM to summarize customer support tickets and draft replies, but require human approval before any message is sent.”

Recommended judgment

• Primary label: Allowed with mitigation.
• Confidence: Medium-high.
• Why: This is not a bright-line prohibited use and does not obviously involve a consequential decision. It does, however, implicate accuracy, confidentiality, logging, human control, and transparency. NIST AI RMF and the Generative AI Profile emphasize governance, content provenance, pre-deployment testing, and incident handling; Japan, Australia, Singapore, and OECD instruments all point toward risk-based governance, accountability, and human control. FTC privacy guidance matters if customer data might be reused beyond promised purposes.

Step-by-step machine trace

Risks, limitations, and mitigations

No matter how carefully built, a judgment machine of this kind will face hard limits.

These mitigations are consistent with the governance and trustworthiness themes across NIST, OECD, UNESCO, Australia, Singapore, Canada, the UK ICO, and the EU AI Act.

The bottom line is that the strongest version of this product is not a browser toy that “judges the user.” It is an offline-capable, citation-backed, jurisdiction-aware legal-and-ethics reasoning interface for AI prompts and deployment scenarios. If built that way, it can be rigorous, useful, and much easier to defend from a compliance and product-trust standpoint.