For security and governance teams

Govern AI agents while they move to production

Duale AI gives security, legal, audit, and platform teams a shared operating model for agent work: data movement, provider choices, policy decisions, available operating signals, and project-specific review paths.
Security Trust Center

Governance as production enablement

The goal is not to block agent projects. The goal is to make them understandable enough to run, review, and improve.
  • See the work boundary

    Define what an agent can receive, what it can return, which tools it can use, and which outputs require project-specific review.

  • Review provider choices

    Understand which model providers the system can use, which policy inputs affect routing, and what data movement follows from that selection.

  • Define review paths

    Define when the system must stop or retry, use a safer route, or send a result to project controls before the workflow expands beyond a pilot.

Where Duale AI runs and what stays customer-owned

Choose the managed service or an eligible customer-hosted deployment. Customers choose and contract with their model providers in both cases.
Duale AI governance postureYour team owns policy choices, provider contracts, and retention requirements. Duale AI is a French company operating the managed service with application data hosted in Germany, tenant isolation, access controls, audit events, and scoped retention options. Model-provider traffic follows the providers selected and contracted by the customer.

For the managed service, Hetzner hosts application data in Germany and Duale AI operates the platform. For an eligible customer-hosted deployment, the customer operates its infrastructure, network, storage, and infrastructure access; Duale AI supplies the supported platform release, deployment specification, upgrade guidance, and product support. The deployment agreement defines the exact responsibility boundary. Write to contact+security@mail.duale.ai to review eligibility.

Shared operating signals for all teams

Engineering, security, audit, and business teams use one account of the same agent task.
  • Available task context

    Use task submissions, retries, failures, terminal results, and review handoff context where captured by the integration.

  • Policy decisions

    Review the policy inputs that shaped routing, provider selection, review paths, and operating context.

  • Incident readiness

    Give the teams responsible for risk and reliability enough context to understand degraded providers, failed executions, and recovery paths.

Review regulated work

Use current product, security, privacy, and operating evidence in each deployment review.
  • European Union AI Act readiness

    Use available review inputs to discuss risk management, logging, transparency, and human oversight expectations where those rules apply.

  • Data protection review

    Use documented processors, hosting, retention, and deletion paths as the starting point for privacy and data-processing reviews.

  • Operational resilience

    Make dependency, provider, recovery, and exit questions visible before a critical workflow becomes hard to replace.

A better relationship with delivery teams

Security and audit teams are rarely the primary buyer. They become more effective when the product already exposes the answers they need.
  • For platform teams

    Build once with the review inputs, routing, and governance context that reviewers will ask for later.

  • For security teams

    Review the product boundary early, then monitor the available runtime signals engineering uses in production.

Governance questions

Make governance a production capability.

Open Trust Center