1. Define the Trust Boundary
Imagine an internal function that prepares an update for a record. The model can read strictly necessary information and propose new fields, but it does not receive database credentials or execute the modification. The conventional application retains control: it authenticates the person, checks their permissions, validates the current state, and decides whether to apply the change. This separation reduces the impact of an erroneous or manipulated response.
Map the data flow before writing code. Identify what the person sends, what context is incorporated, what response is expected, and which systems could be affected. Treat text retrieved from documents, tickets, and records as untrusted data: it may contain misleading instructions and must not expand the model's authority. Avoid including secrets or personal data that are not essential for formulating the proposal.
Define a reduced-scope output. For example, instead of asking the model to update a record, request an object with the record identifier, the fields it proposes to change, and a brief explanation. The explanation can help the reviewer, but it does not replace server-side checks. The model must not decide who is authorized or which business rules apply.
A tool or function call allows a model to request operations available in an application; it does not convert that request into authorization. The application must interpret the request as a proposal and apply its own policy. If the chosen function involves a write, the interface exposed to the model should only allow preparing the operation, not confirming it.
2. Place an Adapter Between the Model and Internal Services
The adapter is application code that translates between the user's request, the model provider's interface, and internal services. It holds credentials, limits the context sent, validates the response, and calls deterministic business operations only after passing checks. Thus, the model does not connect directly to the database or decide how a person is authenticated.
Separate responsibilities into comprehensible modules: authentication and authorization; context construction; model call; output validation; presentation for review; and execution of the confirmed operation. This separation allows changing providers without rewriting business rules and facilitates disabling generation without leaving the conventional function inoperable.
Establish a versioned input and output contract. A structured response may require mandatory fields, specific types, and closed enumerations. Structured output helps reduce format ambiguities, but it does not prove that the values are correct or safe. Validate the object on the server, reject unknown fields if the contract requires it, and check domain-specific rules.
Keep decisions that must be deterministic out of the model: user identity, permissions, resource limits, state transitions, exact calculations, and persistent writes. Integration platform documentation shows patterns for connecting models and workflows, but specific configuration, available connectors, and their permissions depend on the product and must be verified in its current documentation.
Adapter Sequence
The model prepares a proposal; the application decides if it is valid and authorizable.
- 011. Authenticate the person and check they can access the requested resource.
- 022. Retrieve only necessary data and build a request with clearly delimited instructions and context.
- 033. Call the model using credentials stored on the server and defined time limits.
- 044. Validate format, fields, allowed values, and business invariants; reject any invalid response.
- 055. Display the proposal and request confirmation when the operation has persistent effects.
- 066. Re-check permissions and current state before writing via the authorized internal service.
3. Convert the Proposal into an Authorizable Operation
The model's response is not a reliable order. Before applying a change, check that it meets the expected schema, that the resource belongs to the authorized scope, and that the current user can perform exactly that operation. Do not infer authorization from a model explanation, a suggested category, or content found in documents.
Check the record's state immediately before writing. If it has changed since the proposal was generated, do not silently apply values calculated on an older version. You can return the case for review, regenerate the proposal with the new state, or present a conflict for the person to decide. The write must be executed with a concurrency check appropriate to the storage used.
Define business rules independent of the model. For example, a proposal may be syntactically valid but not allowed because the ticket's state is already closed. Limit the number of modifiable fields, reject out-of-range values, and prevent the model from introducing resource identifiers that have not been previously authorized.
Human review is especially useful when the change is sensitive, difficult to reverse, or affects other people. It must be an informed decision: present current and proposed values, indicate which fields will change, and allow cancellation. In regulated contexts, specific obligations depend on the applicable function and classification; AESIA practical guides are directed at implementing the AI Act and are described as non-binding recommendations, not as a substitute for legislation.
Decision Before Writing
Use this matrix as a starting point; adjust controls to the actual impact and system rules.
| Check | If Met | If Failed |
|---|---|---|
| Schema and allowed fields | Continue with business validations | Reject the response and log the technical reason |
| Current identity and authorization | Check the resource and its state | Do not execute; return an authorization or access error |
| State without incompatible changes | Prepare the write with concurrency control | Stop the operation and request review or a new proposal |
| Reversible and low-impact action | Adequate confirmation for the product may suffice | Require explicit review and a recovery procedure |
| Complete response within deadline | Present the valid proposal | Do not convert a partial response into an operation |
4. Limit Credentials, Tools, and Context
Apply the principle of least privilege to each component: a credential should allow only the necessary operations on the necessary resources. If the flow needs to query data and propose an update, separate the read identity from the one that executes writes. Keep the second one out of the model's process and use it only in the server-controlled application path.
Do not expose generic tools to the model, such as executing arbitrary queries, accessing all records, or invoking any internal API. Expose narrow operations, such as getting a summary of an authorized record or preparing a category change. If the platform allows selecting tools or functions, that list is a capability boundary, not a substitute for authorization implemented by the application.
Store keys and tokens in the secret management mechanism approved by the environment; do not include them in instructions, debug logs, or user responses. Define rotation and revocation, separate credentials by environment, and avoid reusing development keys in production. API security mechanisms, such as tokens, keys, or certificates, have different scopes and requirements: verify which one is actually configured in your platform and do not assume that a mechanism name implies minimal permissions.
Also reduce the information delivered to the model. Remove irrelevant fields, hide identifiers when not necessary, and set size limits. Review what data is sent to the provider, the current treatment and retention conditions, and the options available for the region and type of service contracted. These details vary by provider, product, configuration, and date; they cannot be deduced from a general architectural pattern.
5. Manage Timeouts, Retries, and Duplicates
A model call may take time, return an incomplete response, or fail due to a transient interruption. Define a maximum time and treat a response exceeding that limit as an unavailable proposal; do not execute an action based on a partial result. Communicate a clear state and allow retrying without losing the ability to review what was requested.
Distinguish between retrying generation and retrying a write. Requesting a proposal again may produce a different output; therefore, keep the request identifier and show which proposal is being reviewed. In contrast, repeating a write after a timeout may duplicate the effect if the first request did reach the system. Use an idempotency key or equivalent mechanism when the service supports it, and check the result before resending.
An idempotent operation produces the same effective state if repeated under the same conditions; it should not be confused with repeating any request without consequences. For a non-idempotent write, design a way to detect if it was already applied, for example, by logging the operation identifier along with the result. If you cannot establish the result after a failure, stop automatic retry and derive the case to reconciliation.
Protect writes against concurrent changes. Include a version or state condition that the application read and reject the write if it no longer matches. Define what can be reverted: sometimes restoring fields is enough; in other cases, there are external effects or notifications that cannot be undone. In those cases, specify a compensation and who decides to apply it.
6. Deploy in Stages and Keep an Emergency Exit
Prepare a test environment with non-production or properly protected data and separate credentials. Check the full path: proposal generation, rejection of invalid output, denial due to lack of permissions, state conflict, timeout, and write failure. The goal here is to verify the behavior of the chosen integration, not to assume that a provider offers a specific security function.
Start in proposal mode without execution: the application can generate and display results, but not apply changes. Then enable confirmation for a small group or a limited class of operations, with identified responsible parties. Define in advance what condition stops the function, who can activate or deactivate it, and how the change is communicated to users.
Rollback must be a real operational capability. Include a switch that disables generation or action execution without altering existing data, a conventional path to complete the task, and a procedure to review pending proposals. If deployed via an API or pipeline, separate technical deployment from publication to users and verify which phase allows receiving traffic. Details depend on the specific platform.
Before expanding access, document known limits, effective permissions, data treatment, and provider instructions applicable to the chosen configuration. AESIA guides explicitly state that their documents are non-binding recommendations and subject to review; use them as contextual guidance, not as a legal ruling automatically applicable to any integration.
Gradual Deployment with Rollback
Increase scope only when you can demonstrate that the controls of the previous stage work.
- 011. In testing: use isolated data and credentials; verify validation, authorization, and network failures.
- 022. In proposal mode: enable generation and review, keeping all automatic writes blocked.
- 033. In limited enablement: allow confirmation to a small group and for scoped operations.
- 044. Before expanding: check the stop procedure, alternative access, and review of pending operations.
- 055. If a relevant failure appears: disable execution, preserve state, and derive uncertain cases to review.
- 066. To re-enable: identify the cause, apply the change, and repeat relevant checks.
7. Architectural Review Template
Before implementing, answer in writing questions that can be verified in code, configuration, or current documentation. Do not mark a box as resolved because a provider announces a general capability: confirm that this capability exists in the product, version, region, and service level you will use.
Include in the review the exact adapter interface, response schema, deterministic rules, identity of each component, accessible resources, and the path from confirmation to write. Also log error scenarios, retry behavior, duplicate detection method, concurrency conditions, and the mechanism to disable the function.
Keep documented facts, design decisions, and pending hypotheses separate. For example, a platform supporting function calls does not prove that a specific function is independently authorizable. A guide describing authentication mechanisms does not prove which ones are active in your deployment. Confirm each detail in the corresponding primary documentation and effective configuration.
To expand concepts, review the learning guide on AI, the local models guide, and glossary entries on tool calling, least privilege principle, structured output, and prompt injection. These internal links should lead to Inferama pages and complement this guide; they do not replace the chosen provider's documentation.
Verifiable Checklist Before Production
Log concrete evidence —file, configuration, test, or documentation section— for each decision.
| Area | Review Question | Evidence to Keep |
|---|---|---|
| Authority | What can the model propose and what operation requires confirmation? | Adapter contract and authorization flow |
| Data | What fields leave the application and what treatment does the provider declare for this service? | Data list, configuration, and current documentation |
| Permissions | What resources and operations does each credential allow? | Effective policies and denied access test |
| Validation | What happens with unknown fields, invalid values, and obsolete states? | Schema, business rules, and test results |
| Retries | How is a repeated write or uncertain result detected? | Idempotency key or reconciliation mechanism |
| Rollback | Who can stop the function and what is the alternative path? | Tested procedure and assigned responsible |
Open questions
- Details on tool calls, schemas, permissions, data retention, and deployment depend on the provider, product, version, region, and configuration; they must be checked in current primary documentation before implementing.
- The provided sources do not specify a concrete API or library for idempotency keys, concurrency control, or rollback; implementation will depend on the internal services used.
- AESIA practical guides are described as non-binding recommendations, mainly directed at high-risk AI systems; this guide does not determine if a specific case is subject to regulatory obligations.
Keep exploring
Sources consulted
Corrections and transparency
If you spot incorrect or outdated information, send us a correction with the page and source we should review.
Submit a correction