Translation

Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.

ASILO: shelter with keys and boundaries

ASILO helps define what a system built with artificial intelligence (AI) assistance may do, who can stop it and how its limits are checked. Its eight requirements have their own scopes, conditions, exceptions and residual risks.

Its name comes from the Spanish word asilo, understood here as shelter or protection. The protection from design guide explains its origin and the AI first approach. This page turns the shelter metaphor into decisions about an action. This is an informative translation from Spanish.

An everyday situation

Imagine a shelter with a consultation area and a restricted archive. Someone asks to review a document. The request describes the task; entering the archive requires checking identity and permission for that document. A key can be limited to an area and withdrawn. A responsible person reviews actions with significant consequences.

Shelter	System
Request identifying the task	A contract for validating a request.
Checking who presents the request	Authentication.
Checking access to that document	Authorization over an operation and resource.
A limited key that can be withdrawn	A capability with defined scope and revocation.
Access and incident records	Evidence for reconstructing actions and outcomes.

The analogy explains responsibilities. A drawn key implements no authorization, and a correctly formatted request may contain false information. Controls need to be checked in the real system.

From proposal to effect

flowchart TD
  accTitle: ASILO: from proposal to effect
  accDescr: A proposal passes successive decisions: meeting the contract, the identity's permission for the action, human review when the catalogue requires it with approval of the exact object, valid scope with available budget, and permission still valid at the point of effect. Any negative answer leads to rejecting and recording the reason, except missing approval, which leaves the proposal waiting with its state preserved; if everything is met, only the authorised action is performed and its outcome recorded.
  P["Proposal from a person or model"] --> V{"Does it meet the contract?"}
  V -->|No| X["Reject and record the reason"]
  V -->|Yes| A{"May this identity perform this action?"}
  A -->|No| X
  A -->|Yes| H{"Does the catalogue require human review?"}
  H -->|Yes| R{"Is there approval for this exact object?"}
  R -->|No| Q["Wait for a decision and preserve state"]
  R -->|Yes| L{"Is scope still valid and is budget available?"}
  H -->|No| L
  L -->|No| X
  L -->|Yes| E{"Is permission still valid at the point of effect?"}
  E -->|No| X
  E -->|Yes| Z["Perform only the authorised action and record its outcome"]

SVG diagram: ASILO: from proposal to effect · Editable Mermaid source.

The process separates request validation, permission checks, human review where required, and scope and budget checks. Check authorisation again where the action produces its effect; reject the action if permission is no longer valid. When required approval is missing, preserve state and wait for a decision.

This diagram explains a process; it does not replace the conditions and exceptions of ASILO-R-001, ASILO-R-004, ASILO-R-005 and ASILO-R-007.

A first example

An assistant proposes summarising public documents. Reading them and drafting a summary are the task. Sending the draft to someone else is another action: it needs permission and human review where applicable. The summary's format determines neither its truth nor permission to send it.

Continue with context, layered security and evaluation. See the glossary.