Scope and limits: purpose, excluded uses, and behavior

Use Duale AI only for the intended purpose and within the production boundaries below. These instructions for use apply within the meaning of Article 3(15) of Regulation (EU) 2024/1689. They define the intended purpose under Article 3(12), the excluded uses, and the cross-cutting edge guarantees. The terms of use and terms of sale refer to them. Linked capability pages define their focused interfaces and procedures.

What the Platform is for

Duale AI’s core purpose is the orchestration of software agents. The Agent harness defines the Platform boundary and its current objects.

You declare a pool of Model Routes and supply your own provider keys. You write your agents’ instructions, publish custom SDK Tools or assign MCP Connections, and decide what data those Tools receive. The Platform also supplies Built-in Tools. A Task request cannot narrow any of these Tool sets. For each Task, the Platform ranks Model Routes from your pool. One Task can make more than one Provider Attempt before it reaches a terminal outcome.

The Platform produces text. It generates no images, audio, or video. It neither trains nor fine-tunes models.

When you enable an image-capable model in your pool, an agent can receive an image embedded in an indexed document. The Platform’s own output stays text. Data protection states how the image reaches the selected model provider and how the temporary working copy is handled.

That intended purpose covers every function:

• routing;
• analysis that Duale AI performs with its own models rather than with your pool;
• web search and public-page reading;
• running a program an agent writes in fresh, bounded writable state separate from your systems.

An answer whose requested response format is plain text or unset normally carries a machine-readable mark identifying it as machine-generated. Content marking states which answers carry one, how to verify it offline, and when an answer arrives unmarked.

Excluded uses

Do not use or configure the Platform for any use listed in Annex III of Regulation (EU) 2024/1689 (opens in a new tab). Those uses are:

• Biometrics—remote biometric identification, biometric categorization, emotion recognition.
• Critical infrastructure—safety component for water, gas, heating, electricity, road traffic, or critical digital infrastructure.
• Education and vocational training—admission, assessment of learning outcomes, steering a level of education, proctoring.
• Employment—recruitment, targeted job advertising, filtering applications, evaluating candidates, promotion, termination, allocating tasks based on behavior or personal traits, monitoring and evaluating workers.
• Access to essential services—eligibility for public benefits, creditworthiness, credit scoring, risk assessment and pricing in life and health insurance, emergency call triage, dispatching emergency services, patient triage.
• Law enforcement—any use listed in point 6 of that Annex.
• Migration, asylum, and border control—any use listed in point 7 of that Annex.
• Justice and democratic processes—assisting a judicial authority or an arbitrator in establishing facts or applying the law; influencing an election.

These exclusions bind contractually now. Chapter III Sections 1–3 apply from December 2, 2027, for systems classified under Article 6(2) and Annex III, and from August 2, 2028, for systems classified under Article 6(1) and Annex I.

Do not use the Platform as a safety component of a product that requires third-party conformity assessment under Article 6(1) of the same Regulation.

Within the meaning of Article 25(2) of Regulation (EU) 2024/1689, Duale AI expressly specifies that the Platform is not to be changed into a high-risk AI system.

Two common mistakes

Adding a human review step does not, on its own, take a use off that list. Human oversight is an Article 14 requirement for systems already classified as high-risk. Under Article 6(3), an Annex III system is not high-risk only when it poses no significant risk of harm, including by not materially influencing a decision outcome, and one of four listed conditions applies: a narrow procedural task; improvement of a previously completed human activity; detection of decision-making patterns without replacing or influencing the prior human assessment and with proper human review; or a preparatory task. Proper human review belongs to that third condition, not to the other three.

An Annex III system that profiles natural persons remains high-risk regardless of those conditions.

Splitting a use across several agents does not remove it either. Where several AI systems form part of a more complex system and their combined purpose or joint outputs materially influence a decision, the whole configuration is assessed together.

The Article 6 test above follows the current consolidated Regulation. The combined-system point comes from the Commission’s draft guidelines on high-risk classification (opens in a new tab), 2026-05-19, paragraphs 70–71 and 75. Those guidelines remain a draft and bind no one.

If you need one of these uses

Write to contact+highrisk@mail.duale.ai before you start. Duale AI answers within 15 working days. Without a separate signed agreement, the use stays excluded.

Using the Platform for one of these cases would breach its documented intended purpose and requires a separate legal assessment. Under Article 25(1)(c), a deployer or other third party will be considered the provider once Article 25 applies, and only when it changes the intended purpose of a system not classified as high-risk so that the resulting system becomes high-risk under Article 6. An Annex III label does not by itself complete that assessment.

How routing works

You declare the model pool. For Task model work, the Platform uses only enabled routes in the selected Tenant; a routing preference cannot add a route outside that pool. Duale AI’s own analysis uses the separate internal models described above.

Routing contract and limits owns the policy fields, preference behavior, route variability, and analytics boundary. Capability labels describe routing evidence, not an allowed use. The excluded uses above prevail over every label.

Behavior you must plan for

Know these before an agent acts on a live system.

SDK Tool delivery and external Effects

Customer Tool handling is not exactly once. A dispatched Customer Tool Call can fail or time out before customer code receives it. When a Tool Host consumes it, the same (task_id, tool_call_id) can reach your code twice or more. Control duplicate attempts on your side. An intrinsically repeat-safe operation needs no extra claim store solely for delivery. A material non-idempotent or uncertain External Effect needs a durable claim and reconciliation path. If a duplicated call moves money, sends a message, or writes to a third-party system, reconcile the destination before you retry. Define a compensating action where the destination supports one.

Customer Tool delivery and settlement are asynchronous. You set a timeout. If it expires without a Tool Host response, the Platform supplies a timeout Tool Result, and the execution can continue on a best-effort basis. That result does not prove whether the Tool code ran or produced an Effect.

Authoring SDK Tools owns the Tool Host protocol. Secure integration owns the controls that your application applies before an external Effect.

MCP Tool delivery and external Effects

Remote MCP Tool execution is not exactly once. Duale AI does not intentionally retry a logical MCP call when it cannot rule out that the server received the request, but a duplicate can still occur. Make a state-changing operation idempotent where possible.

A remote outcome can remain unknown. If Duale AI cannot rule out that the MCP server received the request and cannot prove its response, the call ends as outcome_unknown. Read the destination system before you retry or compensate. A Tool Result or Analytics count does not prove which External Effect occurred.

Synchronous MCP calls must return one complete supported result. This release supports text and structured results. It does not support interactive input requests, queued MCP Tasks, handles for later retrieval, or media and resource result blocks. Tools reference owns the call contract. Operate Tools owns the visible outcomes and recovery guidance.

Stop requests and running work

A Stop request is asynchronous. sdk.stop_task(task_id, reason) asks the Platform to stop work for the requested Task and every causally downstream Runtime Route. If the Stop commits, it also prevents every Executor under the same root Task from admitting new Runtime Routes. A caller needs agent:stop_task on the Task, and the answer is immediate (stop_task). Acceptance does not confirm that the Task exists or reached a stopped outcome, so observe the Task’s terminal outcome. Revoking a provider key does not cancel work the Platform already accepted. Provider calls already in progress can finish; later calls remain governed by provider access, the accepted Task deadline, and other terminal conditions.

Each Task, including a continuation Task, is stopped by its own identifier. Stopping a parent does not stop its continuations. Do not rely on Stop as the only control over External Effects.

The downstream Stop set has a current cap. When that set contains more than 5,000 Runtime Routes, the Platform accepts the asynchronous request but returns no separate customer-visible rejection when it does not apply the Stop. Execution can continue to another terminal outcome or its deadline. Prevent new External Effects in your application and confirm the Task Outcome.

A Stop that takes effect does not undo work already sent out. It prevents new work in the stopped execution. The Platform does not recall work already dispatched to a model provider, SDK Tool Host, or MCP server. That work can still reach its recipient, finish, and produce an Effect. A Stop does not reverse an Effect; the resulting state can persist.

Runtime ceilings and deadlines

Runtime ceilings are protective backstops, not a customer-settable work budget. They do not define a total per-Task Provider Attempt, token, cost, or latency cap. Split complex work into focused Tasks, and enforce admission, concurrency, and spend limits in your application.

Deadlines are absolute dates, never relative durations. A paused task does not shift its deadline.

A Task’s deadline also budgets final-answer writing. Work can stop before the deadline to leave time for the answer. Final writing can continue for up to five minutes after the Task deadline, using information already collected. That window does not admit new research or customer-hosted Tool Calls. If the answer is not completed within that window, the Task ends as a failure.

Each Task, including a continuation Task, has its own deadline and final-answer writing window of up to five minutes after that deadline. The parent’s deadline does not bound a continuation’s deadline.

Context continuity and human review

On a long task, the Platform sends the model less than the whole history. Well before that history fills the context window of the selected route, it starts sending less of it, oldest first. The Task instruction you submit is sent unchanged on every model call of that Task. Context reduction does not itself delete the stored task history; targeted Recall can retrieve earlier history within the supported Task lineage. The privacy notice and applicable agreement own retention and deletion periods. How the SDK works states what reduction leaves intact.

An interrupted Task can be continued. A continuation Task carries the task history forward with its own deadline. What a continuation Task inherits states what it keeps and for how long.

The Platform builds no human review step for you. For an SDK Tool, your code can enforce the decision. An MCP Connection has only Allow calls or Block calls; it has no per-call Ask policy, approval queue, or wait list. When an applicable law, policy, or impact rule requires a person, place that decision in a separate customer-controlled process or expose a custom SDK Tool that records a proposal. If you do not build the required review step, the Agent can act without it. The Stop request described above is not a review gate, and acceptance is not terminal proof.

What Duale AI records

Duale AI records selected configuration, authorization, Task lifecycle, routing, Tool-dispatch, provider, model, and usage events. Tool Analytics also aggregate terminal logical-call outcomes by Source, Tool, and Agent Identity. Use these records as supporting evidence, not as a complete explanation of an outcome. They do not prove which External Effect occurred, reveal Tool arguments or results, or record every decision and its reason.

Evidence and audit owns the complete record inventory, access and export limits, proof boundary, and the customer evidence that can cover its gaps.

The privacy notice states retention periods. A stated period is a policy and contractual boundary; this record inventory does not prove that an individual record was deleted or stripped of identifying data on schedule.

Who must tell people an AI is involved

The Platform exposes no conversational interface to natural persons. Your code calls it through the SDK and the API.

Assess each Article 50 duty against the integration that people actually encounter. Article 50(1) applies to a provider whose AI system directly interacts with natural persons. The current Commission guidance requires a genuine, direct, two-way exchange and excludes background or machine-to-machine operation. Its notice is unnecessary only when the AI interaction is obvious.

Provider output-marking duties and deployer disclosures for emotion recognition, biometric categorization, deep-fake content, or public-interest text have different conditions. Re-exposing an output does not by itself decide provider status. Articles 3 and 25 make that role depend on development, branding, intended purpose, modification, and high-risk classification facts. See the Commission’s Article 50 guidelines (opens in a new tab) and FAQ (opens in a new tab). For the Agent Identity attribution boundary and its distinction from behavior, see Identity.