Skip to main content

Brazil LGPD: Data Protection Compliance for AI Workflows

Brazil's Lei Geral de Protecao de Dados, Law No. 13,709/2018, already gives AI teams enough privacy law to worry about without waiting for any future AI-specific statute. If your route handles names, customer records, employee files, transaction data, health information, or inferred profiles tied to a person, LGPD is in play. The law's principles in Article 6, its treatment of sensitive personal data, cross-border transfer requirements, security obligations, and the right to review decisions made solely on automated processing all create operational pressure for AI systems.

That pressure lands on the runtime path. Procurement reviews and privacy notices do not stop a generic AI route from oversharing personal data, using the wrong provider, or delivering a consequential output without human review. Keeptrusts helps at exactly that boundary. It can redact or block sensitive data in prompts, restrict provider eligibility according to declared handling guarantees, require escalation for higher-impact routes, and preserve evidence the privacy office can inspect. It does not replace legal-basis analysis, rights handling, or contractual review with operators.

Use this page when​

  • You need an LGPD-aligned technical control pattern for AI assistants, copilots, or automated workflows.
  • You want to govern personal and sensitive personal data in prompts, retrieval context, and outputs.
  • You need a practical answer to automated-decision and cross-border questions in live model routes.

Primary audience​

  • Primary: Privacy officers, compliance managers, platform engineers
  • Secondary: legal teams, security architects, product leaders

The problem​

LGPD issues in AI programs are rarely caused by one dramatic design decision. They usually emerge through accumulation. A support route begins with harmless summaries, then starts handling account disputes. An internal assistant begins with engineering notes, then absorbs employee requests and customer transcripts. A fraud model explanation tool starts as analysis support and becomes an informal decision layer. The technical route stays the same while the legal exposure changes.

That is difficult to defend under LGPD. The law expects purpose limitation, necessity, transparency, security, prevention, accountability, and non-discrimination. It also imposes extra care around sensitive personal data, including health data, biometric data, and information revealing racial or ethnic origin, religious belief, political opinion, trade union membership, and other protected categories. If those data types move through AI routes with no minimization or provider restrictions, the organization cannot honestly say privacy by design is operating.

Article 20 adds another pressure point. Data subjects have a right to request review of decisions taken solely on the basis of automated processing of personal data when those decisions affect their interests. Not every AI assistant triggers that rule, but many organizations drift toward it without noticing. Recommendations become approvals, summaries become rankings, and explanations become justifications for adverse actions.

The solution​

The practical response is route-specific governance grounded in LGPD principles. Use a lighter lane for low-risk productivity and a stricter lane for any workflow processing sensitive data or influencing meaningful outcomes.

Keeptrusts supports that design in four ways. pii-detector reduces personal data exposure before the request leaves your environment. data-routing-policy ensures only providers with the approved posture remain eligible, based on metadata such as zero-data-retention, training opt-out, retention windows, tokenized-input support, and internet-egress controls. human-oversight stops a route from operating as straight-through automation when review is required. audit-logger and evidence exports make the route reviewable by privacy, risk, and legal teams.

This is especially important for LGPD because the law is principle-heavy. Principles become defensible only when they alter runtime behavior. Minimization should reduce actual payloads. Transparency and accountability should be backed by evidence. Human review should exist where the workflow can affect a person's interests.

Implementation​

For an LGPD-sensitive route that handles Brazilian customer or employee information, use a configuration like this:

pack:
  name: brazil-lgpd-sensitive-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: brazil-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
        accepts_tokenized_input: true
        allow_internet_egress: false

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

policy:
  pii-detector:
    action: redact
    detect_patterns:
      - 'CPF\s*:?\s*\d{3}\.\d{3}\.\d{3}-\d{2}'
      - 'CNPJ\s*:?\s*\d{2}\.\d{3}\.\d{3}/\d{4}-\d{2}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-BR-ID]"

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

  human-oversight:
    action: escalate

  audit-logger: {}

The exact pattern should vary by route. A marketing drafting assistant may not need escalation. A fraud review, employee support, or claims-related workflow often does. The important part is that the route reflects the data sensitivity and downstream impact you identified in your LGPD analysis. If a workflow involves higher sensitivity or stronger residency requirements, combine this with Regulated Execution and a tighter deployment profile.

Results and impact​

When organizations adopt this model, LGPD reviews become easier to operationalize. Privacy teams can inspect the route and see what is redacted, which providers are still eligible, and whether higher-impact outputs require human review. Engineering gets a fail-closed path instead of a best-effort guideline. Product teams gain clearer boundaries for when an assistant can remain low risk and when it needs a controlled lane.

This also reduces the most dangerous form of compliance drift: silent expansion. A route can evolve in business importance without evolving in governance. Route-level controls make that drift visible and easier to correct before it becomes an incident or regulatory issue.

Key takeaways​

  • LGPD already creates strong AI governance expectations around minimization, security, transfers, and automated-decision review.
  • Route-specific controls are more defensible than one generic AI path for every use case.
  • pii-detector, data-routing-policy, and human-oversight map well to the runtime part of LGPD compliance.
  • Evidence exports make accountability real because the route's behavior can be reviewed after the fact.
  • Legal basis, notices, rights handling, and operator contracts still sit outside the gateway.

Next steps​