Skip to main content

Digital Services Act: Platform AI Governance Requirements

The Digital Services Act, Regulation (EU) 2022/2065, is not an AI statute. It is a platform-governance regulation for intermediary services, online platforms, and very large online platforms and search engines. But AI now sits inside many DSA-sensitive workflows: content moderation triage, seller-risk analysis, notice classification, ad-review support, recommender explanations, and customer-facing support. That means the quality of your AI control layer can affect whether platform decisions are explainable, reviewable, and operationally disciplined. Keeptrusts helps by inserting a governed gateway between those workflows and upstream model providers. It does not satisfy the whole DSA on its own, and it does not replace your legal analysis, transparency reporting, or notice-and-action design.

Use this page when​

  • You run an online platform, marketplace, social product, or trust-and-safety workflow that uses AI for moderation, ranking support, or user communications.
  • You need to turn DSA-facing governance expectations into concrete runtime controls.
  • You want a technical pattern that distinguishes low-risk support automation from high-sensitivity decision support.

Primary audience​

  • Primary: Platform compliance leads, trust-and-safety engineers, product security teams
  • Secondary: Legal operations, marketplace risk teams, platform architects

The problem​

The DSA expects platforms to operate with more discipline around transparency, complaint handling, systemic risk, and platform governance. AI complicates that because it often enters the stack sideways. A moderation team starts using LLMs to summarize notices. A seller-integrity team uses models to classify suspicious listings. A support team uses AI to draft explanations for users whose content was restricted. Each workflow feels narrow, but together they can shape decisions that the DSA expects you to explain and govern.

The common failure mode is to treat all of those workflows as one generic AI feature. The same prompt path serves moderation triage, policy interpretation, and customer messaging. There is no real separation between an internal drafting tool and a route that influences enforcement action. Sensitive case text reaches providers with only informal instructions about what not to paste. Teams log that a request happened, but cannot show which policy chain ran, whether a reviewer had to approve the output, or whether the assistant cited the rule it relied on.

That is a weak operating model for DSA-facing platform functions. The DSA does not require you to eliminate automation, but it does push you toward documented controls, reviewable decisions, and proportionate risk management. If an AI route can influence a statement of reasons, a trader suspension explanation, or a moderation queue outcome, then the route should be governed like a sensitive operational path, not a casual productivity add-on.

The solution​

Keeptrusts is most useful here as an enforcement boundary for platform AI routes. It does not generate your DSA legal position. It gives you a deterministic place to protect the request boundary, constrain provider eligibility, verify grounded outputs, and force human review where a route should never publish content directly.

For notice triage and moderation support, start by separating internal analysis from outward-facing communication. An internal summarization route might use request-boundary protections and privacy controls, while a user-facing explanation route should usually add grounding and review controls. That keeps a model from producing an unsupported policy rationale that looks final when it should still be draft material.

For recommender or marketplace-governance support, the same principle applies. If AI is used to summarize risk indicators, explain a seller-control policy, or draft internal escalation notes, use one route. If the route influences a user-visible statement or a moderation action package, use a stricter route with evidence and review.

The Keeptrusts controls that matter most are already documented. Prompt Injection Detection protects the request boundary from hostile instructions or fake role tokens. PII Detector redacts identifiers and case references before the upstream call. Data Routing Policy limits which providers can participate based on declared retention and training metadata. Citation Verifier helps when a route must ground its explanation in policy text, trust-and-safety guidance, or approved context documents. Human Oversight acts as an escalation switch so the route returns a review result instead of normal assistant content. Audit Logger marks audit logging as part of the active chain while platform storage and exports are handled elsewhere.

Implementation​

One practical pattern is a platform-enforcement explanation route. It is used only after an internal system has already classified the event. The model may draft a reviewer-facing explanation, but it cannot publish it directly.

pack:
  name: dsa-enforcement-explanation-route
  version: "1.0.0"
  enabled: true

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

policies:
  chain:
    - prompt-injection
    - pii-detector
    - data-routing-policy
    - citation-verifier
    - human-oversight
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "reveal.*system.*prompt"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'CASE-\\d{8}'
      - 'LISTING-\\d{10}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-PLATFORM-ID]"

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

  citation-verifier:
    require_sources: true
    require_source_match: true
    extract_patterns:
      - regulatory
      - url
      - quote
    rag_context:
      verify_against_context: true
      min_context_overlap: 0.7
    output_action:
      unverified_action: block

  human-oversight:
    action: escalate

  audit-logger: {}

This route is intentionally stricter than a generic support assistant. The explanation can be drafted, but it cannot go directly to the user. The gateway protects the request boundary, redacts internal identifiers, restricts providers, blocks ungrounded output, and returns an escalated result for human review.

The important operational point is to keep the route narrow. Use it for platform-enforcement explanations, not for every internal query. If you overload one chain with too many jobs, you get noisy evidence and weak governance. Route separation is what makes the control model explainable.

Results and impact​

Teams that apply route separation usually see three improvements quickly. First, trust-and-safety operations become easier to explain internally because there is a visible distinction between internal analysis and outward-facing explanation. Second, platform compliance teams get more usable evidence because the route itself expresses what controls were active. Third, reviewer workflows get cleaner because escalation is deliberate instead of improvised after a bad draft is already circulating.

That does not mean Keeptrusts turns the DSA into a configuration problem. You still need platform terms, notice-and-action procedures, appeal handling, transparency design, and, where relevant, systemic risk governance. But the runtime path becomes much easier to defend. Instead of saying "we ask teams to use approved models," you can say which route handled a DSA-sensitive workflow, what controls applied, and how review was enforced.

Key takeaways​

  • The DSA is a platform-governance regime, not a standalone AI law, but AI routes can still affect DSA-sensitive outcomes.
  • Separate internal analysis routes from user-facing explanation routes.
  • Use grounded-output and review controls where AI assists with enforcement explanations or platform-policy communication.
  • Keeptrusts provides runtime enforcement and evidence, not notice-and-action logic or final legal determinations.
  • Narrow route design is more defensible than one generic platform AI policy.

Next steps​