Skip to main content

Illinois BIPA: Governing Biometric Data in AI Systems

Illinois' Biometric Information Privacy Act, 740 ILCS 14, remains one of the most operationally important privacy laws for AI teams because it targets a category of data that many organizations treat too casually. Voiceprints, fingerprints, scans of hand or face geometry, and related biometric information are not just another field in a customer table. They are data types with explicit notice, consent, retention, and disclosure expectations, backed by a private right of action that has already driven real litigation risk.

That matters for AI systems because biometric data increasingly appears in live workflows. Contact-center copilots may summarize calls from systems that also store speaker verification outputs. Security tools may use facial recognition or selfie matching before handing results to an agent. Workforce systems may combine timekeeping, fraud detection, and voice analysis. Keeptrusts helps at the runtime boundary by enforcing provider restrictions, requiring human review for higher-impact uses, and preserving evidence about how the route behaved. It does not replace the written release, public retention policy, or template lifecycle management that BIPA requires outside the gateway.

Use this page when​

  • You operate AI workflows in Illinois that use or receive biometric identifiers or biometric-derived signals.
  • You need a practical way to separate low-risk assistance from identity, employment, or access-control decisions.
  • You want to describe clearly what Keeptrusts can enforce technically and what still belongs to privacy, legal, and application teams.

Primary audience​

  • Primary: Privacy officers, compliance managers, platform engineers
  • Secondary: security architects, legal counsel, identity and fraud teams

The problem​

BIPA creates pressure at several points in the AI stack at once. The collection problem is obvious: if an application captures a face scan, fingerprint, or voiceprint, the organization needs the required notices and written release where the law applies. The less obvious problem is downstream spread. Once a biometric template, similarity score, verification result, or related case record is available, teams often pass it into AI-assisted workflows as if the data had become ordinary text.

That is where governance usually breaks. A support analyst pastes a fraud case into a copilot, including a face-match result and a template reference. A workforce manager asks an assistant to summarize attendance anomalies linked to voice-authenticated clock-ins. A security analyst routes identity-investigation notes through a general-purpose model because the route is already available. The application may no longer be handling the raw face scan, but it is still handling biometric information or data derived from it in a way that can affect individuals.

BIPA also punishes vague retention behavior. If the business cannot explain where biometric-adjacent data goes, which providers can process it, or when human review is mandatory, it becomes difficult to defend the system design. The risk is not only disclosure. It is uncontrolled reuse. A route built for case summarization can quietly turn into a decision support tool for access denials, fraud interventions, or employment actions.

Keeptrusts does not inspect raw face embeddings or create BIPA consent records. It does stop a biometric-sensitive AI route from using the wrong provider, force review before consequential outputs, and make the runtime path auditable.

The solution​

The safest pattern is route separation. Treat biometric-adjacent AI as a governed lane, not as a variant of the organization's general assistant.

In Keeptrusts, that usually means three things. First, use data-routing-policy to limit providers to the set your privacy and security teams have actually approved for biometric-sensitive traffic. The policy checks declared data_policy metadata such as zero-data-retention, training opt-out, retention windows, in-memory handling, and local-only processing. Second, use human-oversight for any route whose output could materially influence identity verification, fraud escalation, workplace monitoring, or access decisions. Third, use audit-logger and evidence exports so you can show how the governed route behaved during review.

pii-detector is still useful here, but with the right expectation. It can redact request text, detect custom identifiers, and help reduce the spread of case references, employee IDs, and other sensitive metadata before an upstream call. It should not be described as a raw biometric-template detector. For BIPA use cases, the point is to reduce incidental data exposure around biometric workflows and keep biometric-derived processing in the right lane.

If you need stronger privacy guarantees for regulated or high-risk deployments, Regulated Execution adds tokenization, approval controls, and signed evidence. That is particularly useful when your legal and privacy teams want a hard statement that sensitive content is not leaving the trust boundary in raw form.

Implementation​

For a biometric-review route that summarizes identity or fraud cases but must fail closed when the approved provider posture is unavailable, use a configuration like this:

pack:
  name: illinois-biometric-review
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: biometric-reviewed-provider
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        allow_internet_egress: false
        local_only_processing: true

policies:
  chain:
    - pii-detector
    - data-routing-policy
    - human-oversight
    - audit-logger

policy:
  pii-detector:
    action: redact
    detect_patterns:
      - 'VOICEPRINT-[A-F0-9]{10,}'
      - 'FACE-TEMPLATE-[A-F0-9]{10,}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-SENSITIVE-ID]"

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  human-oversight:
    action: escalate

  audit-logger: {}

This does not solve BIPA end to end. It does solve the runtime part that many organizations leave vague. Template references and case identifiers are redacted from prompt text when possible. Provider selection is narrowed to a reviewed posture. If no compliant provider is available, the request is blocked instead of silently falling back. Most importantly, the route cannot produce a directly delivered answer for a high-impact biometric workflow because human-oversight requires escalation.

Pair that with an application rule that raw biometric templates and enrollment payloads stay out of general prompt flows entirely. Where those artifacts must exist, keep them in the dedicated identity or biometric system and pass only the minimum reviewed context into the governed AI route.

Results and impact​

When teams adopt this pattern, BIPA discussions become more concrete. Privacy counsel can review one route and see the approved provider posture. Security can verify that no-open-ended fallback exists. Operations can distinguish a summarization workflow from an identity decision workflow. The platform team gets a technical answer to a legal question: how do we prevent biometric-sensitive AI from behaving like a generic assistant?

This also reduces litigation-driven cleanup work later. Many BIPA problems begin as ordinary product expansion. Route-level controls make that drift visible because a new use case either fits the governed lane or requires a redesign.

Key takeaways​

  • BIPA is about more than collection. It also creates pressure around disclosure, retention, and downstream reuse of biometric-related data.
  • Keeptrusts is strongest at the runtime boundary: provider filtering, escalation, and evidence, not consent capture or biometric enrollment.
  • pii-detector is useful for redacting identifiers and case metadata around biometric workflows, but it should not be described as a raw biometric-template scanner.
  • data-routing-policy and human-oversight are the core controls for biometric-sensitive AI routes.
  • Route separation is the practical way to stop a low-risk assistant from becoming a consequential biometric decision tool.

Next steps​