A cloud AI deployment is ready for review when its owner can explain what data enters, which identity accesses each dependency, how failures are observed and how a previous working version is restored. An endpoint returning a successful response is only one part of that evidence. Use the checklist below before increasing traffic.
Draw a small architecture first
Illustrative system: a web application sends an authorized request to a queue; a worker retrieves the allowed document, calls an approved model endpoint and returns a draft for human review. A separate store records task state. This is an example architecture, not a service installed by CloudAI.
Mark the account, region and owner for each component. Include error storage, backups, monitoring and administrator access in the drawing. A region label alone does not settle contractual, privacy or legal obligations; verify actual data flows and applicable requirements with the responsible team.
Secrets and permissions
AWS recommends temporary credentials through roles for workloads and least-privilege access. Its Secrets Manager guidance covers protecting and managing secrets. Keep credentials out of article examples, source code, command history and unrestricted logs. Check the official instructions for the service actually selected.
| Area | Evidence to collect | Owner decision |
|---|---|---|
| Identity | Roles, required actions, resources and denied unrelated access. | Approve the narrow scope. |
| Data | Allowed inputs, destinations, retention and deletion path. | Approve the processing. |
| Release | Model, prompt, application and configuration versions. | Approve this combination. |
| Recovery | Previous release and compatible task state. | Confirm a usable rollback. |
Logs that answer operational questions
Record a task identifier, component, version, timing and outcome where appropriate. Decide whether input or output content is needed at all before collecting it. A full prompt can contain confidential information; storing it indefinitely because debugging is easier creates another data store to govern.
Separate “request accepted”, “model responded” and “task approved”. The first two do not establish a correct result. Set access controls and retention for logs and verify that alerts identify a person who can act. Avoid publishing real account identifiers or customer examples in screenshots.
Failure paths to demonstrate
- A missing required input stops before the external call.
- A model timeout leaves a visible pending or failed state.
- A duplicate request does not send the same external message twice.
- A dependency denies access without widening permissions automatically.
- A rejected draft remains distinguishable from an approved result.
- A rollback has a documented effect on queued work.
Use authorized synthetic cases and record the actual observations. A checklist entry without evidence is a planned control. If a retry can repeat a side effect, define an idempotency rule before enabling it.
Release and rollback decision
Keep the previous working artifact and its configuration available. Explain whether restoring it also requires a compatible data schema or queue format. Do not assume rolling back model selection reverses a message already sent or data already changed.
A staged release can limit the first workload while the team checks quality, latency, errors and complete cost per accepted task. Choose thresholds from business requirements and observed baseline, not a universal number in a tutorial. The managed versus self-hosted decision worksheet and billing comparison help complete the infrastructure review.
Further reading
- Related reference — cloudai.pt
- Related reference — cloudai.pt
- European Commission — The enforcement framework of the AI Act
- EU AI Act Implementation Timeline
- Related reference — nvlpubs.nist.gov
- Taylor Wessing — GPAI obligations under the EU AI Act