---
{
  "title": "Estandarizamos cómo obtener datos de salud. Nunca estandarizamos lo que un agente puede hacer con ellos.",
  "description": "FHIR resolvió quién puede leer el historial de un paciente. Nunca resolvió qué puede hacer un agente de IA con ese historial a continuación. Aquí se explica la brecha y se presenta un ejemplo ejecutable con Aidbox que la cierra en parte.",
  "date": "2026-08-24",
  "author": "Eugene Vestel",
  "reading-time": "12 min read",
  "tags": ["AI / Agents", "Compliance", "FHIR Standard", "Aidbox"],
  "tldr": "El modelo de autorización de FHIR responde a preguntas de acceso: ¿puede este cliente leer este recurso? No dispone de vocabulario para preguntas de uso: ¿puede el lector conservar una copia, enviarla a un proveedor de modelos, entrenar con ella o actuar sobre una inferencia? Los prompts no son mecanismos de control, por lo que los controles deben ejecutarse en el servidor: redactar en la lectura, auditar cada llamada, reforzar la autenticación en escrituras y exigir aprobación fuera de banda para cualquier acción irreversible. HealthClaw Guardrails es un proxy con licencia MIT que implementa esos cuatro controles; esta entrada explica cómo ejecutarlo frente a Aidbox.",
  "utm-campaign": "ai",
  "utm-content": "agent-guardrails"
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---

Una mujer que conozco tiene tres enfermedades crónicas, cuatro médicos prescriptores y registros en seis sistemas distintos. Antes de cada nueva cita realiza el mismo trabajo: acceder a tres portales, capturar pantallas de su lista de medicamentos, volver a escribir su historial en un formulario de papel y confiar en que el personal de recepción lo introduzca correctamente. Lleva once años haciendo esto. No es una mala paciente. Está realizando una labor de integración no remunerada porque ningún otro actor del sistema está en posición de hacerlo.

Ese es el cuello de botella. No el diagnóstico, no el acceso a los datos en sentido legal. La paciente es la única parte que tiene la imagen completa y la única sin herramientas para actuar sobre ella.

Un agente de IA es lo primero que cierra de forma plausible esa brecha. Puede leer en seis sistemas, conciliar una lista de medicamentos, rellenar el formulario y gestionar la derivación. Esto no es especulativo. Conecte un cliente MCP a un servidor FHIR, proporciónele una URL base y un token, y la demo funciona al primer intento.

Y ese es exactamente el problema. La demo funciona, y nada en la pila le indica a la paciente qué puede hacer ese agente con lo que acaba de leer.

## Para qué fue diseñado FHIR, y para qué no

El modelo de autorización de FHIR se construyó para un mundo en el que el cliente era una aplicación y detrás había una persona. Ese mundo empezó alrededor de 2011, se consolidó a través de Argonaut y SMART on FHIR, y se convirtió en ley con las reglas de API de la Ley del Siglo XXI de las Curas. Resolvió un problema real, y lo resolvió bien. Un paciente puede ahora obtener sus datos.

Observe lo que dicen realmente los ámbitos de autorización. `patient/Observation.rs` significa que este cliente puede leer y buscar Observations para este paciente. Esa es una pregunta de acceso, y FHIR la responde con precisión.

Ahora plantee las preguntas que suscita un agente:

- ¿Puede este lector conservar una copia una vez finalizada la sesión?
- ¿Puede enviar el payload a un proveedor de modelos en otra jurisdicción?
- ¿Puede el proveedor retenerlo en una caché de prompts?
- ¿Puede utilizarse para entrenar un modelo que otra persona comercialice?
- ¿Puede el lector inferir un diagnóstico y actuar sobre esa inferencia en un lugar que el paciente nunca ve?

FHIR no responde a ninguna de estas preguntas, porque ninguna es una pregunta de acceso. Son preguntas de uso, y el uso era un problema de otro cuando se redactó la especificación. `Consent` es el que más se aproxima: expresa el permiso para divulgar, con disposiciones sobre finalidad de uso y actores. Aun así, describe un permiso concedido en la frontera. Nada en el recurso viaja con el payload y nada en el destinatario lo hace cumplir. R6 introduce `Permission` con una operación `$evaluate`, lo que supone un avance genuino que todavía se encuentra en fase de votación.

Por tanto, la formulación honesta de la brecha es la siguiente: el estándar regula quién puede leer. No regula qué puede hacer el lector a continuación, y no dispone de vocabulario para un lector que es un modelo en lugar de una persona.

Esto no es una crítica a FHIR. Grahame y todos los que lo construyeron estaban resolviendo el problema de 2014, y el problema era real. Es una declaración sobre lo que 2026 necesita y que todavía no existe.

## Nadie está construyendo el lado del paciente en esto

Hay trabajo real en marcha aquí, y merece ser nombrado. La CARIN Alliance tiene un código de conducta para el intercambio dirigido por el consumidor. Los SMART Health Links de Josh Mandel proporcionaron a los pacientes un mecanismo genuino para compartir un registro en sus propios términos. El Consent IG existe. Los grupos de trabajo de HL7 están implicados.

Pero observe quién está construyendo las herramientas de gobernanza de IA y para quién. Los proveedores están incorporando la seguridad de los agentes en sus propios productos, limitada a su propia responsabilidad. Los sistemas de salud están redactando políticas de IA que rigen los agentes del sistema dentro del perímetro del sistema. Ambas actitudes son racionales. Ninguna produce algo que controle el paciente.

La asimetría es el punto central. Cuando un sistema de salud despliega un agente, el sistema decide la política de redacción, conserva el rastro de auditoría y establece las reglas de aprobación. Cuando un paciente utiliza un agente sobre sus propios registros, el paciente no decide ninguna de esas cosas. Acepta lo que el proveedor de la aplicación eligió, generalmente sin verlo, y el proveedor de la aplicación no tiene incentivo para elegir de forma conservadora.

Estamos a punto de poner en manos de los pacientes la herramienta más potente que han tenido jamás para navegar por este sistema, sin ninguna capa de gobernanza que ellos controlen. Eso merece una reflexión incómoda.

## Lo que realmente vale la copia

Esta es la razón por la que no se trata de una preocupación abstracta. Cuando un recurso FHIR completamente identificado sale de la entidad cubierta y llega a un proveedor de IA de uso general, HIPAA normalmente deja de aplicarse. No existe un acuerdo de socio comercial con un chatbot de consumo. Lo que rige los datos allí es la aplicación de la ley por parte de la FTC y un mosaico de legislación estatal, que es un régimen más débil para el individuo.

Cuatro cosas pueden ocurrirle a esa copia.

**Se vende.** El mercado de intermediación de datos de salud está consolidado. Los compradores incluyen anunciantes, comercializadores farmacéuticos y proveedores de reclutamiento para ensayos clínicos que pagan por cohortes a nivel de condición. Las acciones de la FTC en 2023 contra GoodRx y BetterHelp implicaron datos de salud que llegaron a plataformas publicitarias desde empresas que habían comunicado a los usuarios que no lo harían. Ningún hospital estuvo involucrado en ninguno de los dos casos.

**Llega a un asegurador.** La Ley del Cuidado de Salud a Bajo Precio prohíbe a las aseguradoras de salud suscribir pólizas basándose en condiciones preexistentes. No prohíbe a las aseguradoras de vida, incapacidad o cuidados de larga duración hacerlo, y estas sí suscriben basándose en el historial de salud. La exposición del empleador se produce a través de los programas de bienestar y la administración de planes autofinanciados, donde la separación entre los datos del plan y los del empleador es más delgada de lo que la mayoría de los empleados supone. GINA y la ADA limitan parte de esto. Ninguna de las dos fue redactada pensando en condiciones inferidas a partir de una transcripción de chat.

**Le coloca en una cohorte.** Una vez que un tercero puede inferir sus diagnósticos, puede ser incluido en un programa de divulgación al que nunca se apuntó, o se le puede mostrar un conjunto más reducido de opciones de proveedores del que existe. Si el dirigismo se produce a escala hoy en día es discutible. El incentivo no lo es, y el paciente no tiene visibilidad en ninguno de los dos sentidos.

**Entrena un modelo.** Según las condiciones del proveedor, los inputs pueden convertirse en datos de entrenamiento, y los niveles de consumo difieren considerablemente de los niveles empresariales exactamente en este punto. Este es el único elemento de la lista que no puede deshacerse. La copia de un intermediario puede eliminarse. Los pesos no pueden des-entrenarse.

Ninguna de estas situaciones requiere que nadie actúe de mala fe. Son el comportamiento predeterminado de un sistema en el que el paciente concedió acceso de lectura y nada aguas abajo está restringido.

## Las instrucciones no son control de cumplimiento

La respuesta habitual es escribir mejores instrucciones. Poner las reglas en el prompt del sistema. Decirle al agente que redacte los identificadores, registre sus acciones y pregunte antes de escribir.

Un prompt es una solicitud, no un control. El modelo decide si lo cumple, y cualquiera que pueda poner texto frente al modelo tiene voto. Las notas clínicas, los documentos escaneados y los mensajes del portal son todos texto que un atacante puede manipular. Un control del que el agente puede salirse mediante el diálogo no es un control.

El cumplimiento debe ejecutarse donde el agente no puede alcanzarlo. En la práctica, eso significa el servidor, y significa cuatro cosas.

**Redactar en la lectura.** Eliminar los campos de clase identificadora antes de que el recurso llegue al modelo. Nombres reducidos a iniciales, identificadores enmascarados, direcciones eliminadas, fechas de nacimiento truncadas al año. El agente obtiene contenido clínico pero no identidad. Esto es un control compensatorio, no una determinación legal de desidentificación, y debe describirse como tal. No hace que un registro con un diagnóstico poco frecuente y una secuencia de fechas inusual sea imposible de vincular. Lo que cambia es el comportamiento predeterminado, que actualmente es «entregar todo».

**Auditar todo.** Cada lectura y escritura emite un registro duradero que nombra el inquilino, el agente, el recurso y el momento. Un registro de solicitudes no es esto. Cuando un responsable de cumplimiento pregunta qué agente, actuando para qué paciente, leyó qué recursos, un registro de acceso que lleva una identidad de cuenta de servicio compartida no puede responder. Dos reglas de diseño importan: el rastro es de solo anexión y el detalle de auditoría está libre de PHI, de modo que el registro que se entrega a un revisor es seguro de entregar.

**Reforzar la autenticación en escrituras.** A nivel de protocolo, un token que puede realizar `GET /Observation` normalmente puede realizar `POST /Observation`. El transporte no distingue «resume mis análisis» de «registra una tensión arterial de 190/120». Requerir una credencial separada de corta duración para las escrituras no detiene por sí solo a un atacante decidido. Convierte las escrituras en una clase de evento distinta y auditable en lugar de un efecto secundario de una sesión conversacional.

**Exigir aprobación fuera de banda para cualquier acción irreversible.** Para una escritura clínica, bloquear hasta que un humano confirme. Para una acción en el mundo real, como una llamada, un mensaje de texto o un formulario enviado, el listón es más alto: la confirmación solo debe enviar la acción, con la ejecución condicionada a una aprobación que la propia cadena de herramientas del agente no puede producir. Si el agente puede suministrar el artefacto que representa el consentimiento humano, no hay ningún humano en el bucle.

La objeción obvia: los ámbitos de SMART y `Consent` ya hacen parte de esto. En parte es cierto, y es donde el patrón debería residir eventualmente. Los ámbitos restringen lo que un cliente puede solicitar. Lo que no pueden hacer es restringir la forma de la respuesta, producir un registro de auditoría atribuido al agente, o retener una escritura hasta que una persona confirme. Estos son comportamientos en tiempo de ejecución, y hoy ningún servidor los implementa por defecto.

## Una implementación, construida en abierto

HealthClaw Guardrails es un proxy con licencia MIT entre cualquier agente de IA y cualquier servidor FHIR. Expone un servidor MCP con 29 herramientas y una fachada REST, y aplica los cuatro controles anteriores más el aislamiento de inquilinos. La regla de diseño es que ninguna propiedad de seguridad depende del comportamiento del cliente.

```mermaid
flowchart LR
    A[AI Agent] --> B[MCP Server]
    B --> C[Guardrail Proxy]
    C --> D["Any FHIR Server<br/>(Aidbox, HAPI, Epic, ...)"]
    C -.- E["PHI redaction<br/>Audit trail<br/>Step-up auth<br/>Human-in-the-loop<br/>Tenant isolation"]
```

Hay dos detalles en los que este patrón suele filtrarse.

**La ruta de escritura.** `fhir_propose_write` valida y previsualiza sin confirmar. `fhir_commit_write` requiere un token de autenticación reforzada y devuelve HTTP 428 hasta que un humano confirma. Para las acciones en el mundo real, `action_commit` devuelve `202 awaiting_confirmation` y no hace nada más; la ejecución consume una credencial de un solo uso a través de una ruta de aprobación separada, reclamada de forma atómica para que no pueda reproducirse. Una versión anterior condicionaba esto con una cabecera de solicitud `X-Human-Confirmed`. La eliminamos del flujo de acciones, porque una cabecera puede ser falsificada por quien la establece. Esa cabecera todavía condiciona las escrituras clínicas FHIR hoy en día, y la documentamos como control compensatorio en lugar de prueba de que actuó un humano. Ser precisos sobre qué garantías son criptográficas y cuáles son convenciones es la mayor parte del valor aquí.

**Reescritura de URL de upstream.** Las respuestas se reescriben para que la URL base del servidor subyacente nunca llegue al cliente. Un agente que aprenda el endpoint real intentará enrutar alrededor del proxy.

## Ejecutarlo frente a Aidbox

El ejemplo completo, incluyendo `docker-compose.yaml`, datos de semilla y un recorrido guiado mediante scripts, está en [aidbox-integrations/healthclaw-guardrails](https://github.com/Aidbox/examples/tree/main/aidbox-integrations/healthclaw-guardrails) en el repositorio de ejemplos de Aidbox.

Obtenga una licencia gratuita de Aidbox en [aidbox.app](https://aidbox.app), y luego:

```bash
git clone https://github.com/Aidbox/examples
cd examples/aidbox-integrations/healthclaw-guardrails
cp .env.example .env          # paste AIDBOX_LICENSE, set STEP_UP_SECRET
docker compose up -d
./scripts/seed-aidbox.sh      # one Patient, three Observations, one Condition
```

Se levantan tres servicios: Aidbox en el puerto 8080 como sistema de registro, el proxy de guardarraíles en el 5000, y el endpoint MCP en el 3001 al que se conecta el agente. Aidbox está configurado con una `AccessPolicy` que limita el cliente del guardarraíl al endpoint FHIR, y el proxy apunta hacia él:

```yaml
healthclaw:
  environment:
    FHIR_UPSTREAM_URL: http://aidbox:8080/fhir
    STEP_UP_SECRET: ${STEP_UP_SECRET}
    READ_AUTH_ENABLED: "true"
```

Nada del lado de Aidbox es inusual. Eso es deliberado. La capa de guardarraíles es aditiva, y el servidor FHIR subyacente sigue comportándose como un servidor FHIR.

### La misma lectura, con y sin gobernanza

Directamente a Aidbox, el registro está completamente identificado, como debe ser:

```bash
curl -u "$AIDBOX_CLIENT:$AIDBOX_SECRET" \
  http://localhost:8080/fhir/Patient/pt-demo
```

```json
{ "resourceType": "Patient", "id": "pt-demo",
  "name": [{"given": ["Maria"], "family": "Alvarez"}],
  "identifier": [{"system": "urn:mrn", "value": "MRN-88214"}],
  "birthDate": "1974-03-11",
  "address": [{"line": ["221 Baker St"], "city": "Pittsburgh"}] }
```

A través del proxy, el mismo recurso, el mismo Aidbox:

```bash
curl -H "X-Tenant-ID: demo" \
  http://localhost:5000/r6/fhir/Patient/pt-demo
```

```json
{ "resourceType": "Patient", "id": "pt-demo",
  "name": [{"given": ["M."], "family": "A."}],
  "identifier": [{"system": "urn:mrn", "value": "***masked***"}],
  "birthDate": "1974",
  "meta": {"tag": [{"code": "redacted"}]} }
```

Aidbox sigue almacenando el registro completo. La redacción es una propiedad de la ruta que utiliza el agente, no una modificación de los datos.

### La lectura dejó un registro

```bash
curl -H "X-Tenant-ID: demo" "http://localhost:5000/r6/fhir/AuditEvent?_count=1"
```

Devuelve un `AuditEvent` que nombra el inquilino, el agente, `Patient/pt-demo` y la marca de tiempo, sin PHI en el detalle. `$export` emite el rastro como NDJSON para un SIEM.

### Una escritura, bloqueada dos veces

Pida al agente que registre una tensión arterial. En el primer intento, sin token de autenticación reforzada, devuelve 401. Acuñe un token e inténtelo de nuevo, y devuelve 428 pendiente de confirmación humana. Solo después de la confirmación llega la Observation a Aidbox. Verifique que llegó consultando Aidbox directamente, pasando por alto el proxy:

```bash
curl -u "$AIDBOX_CLIENT:$AIDBOX_SECRET" \
  "http://localhost:8080/fhir/Observation?subject=Patient/pt-demo&code=85354-9"
```

El recurso está ahí, y el rastro de auditoría registra quién lo propuso, quién lo aprobó y cuándo. Esa secuencia es el argumento completo. El agente hizo un trabajo útil. No pudo terminarlo solo.

### Calificar el despliegue

```bash
curl "http://localhost:5000/r6/fhir/\$conformance?format=text"
```

```text
HealthClaw Guardrail Conformance — http://localhost:5000 [tenant=demo]
  Grade: A   (7/7 properties)

  [PASS] PHI Redaction            [PASS] Human-in-the-Loop
  [PASS] Immutable Audit Trail    [PASS] Tenant Isolation
  [PASS] Step-Up Authorization    [PASS] Medical Disclaimers
  [PASS] Error Fidelity
```

La fidelidad de errores es la propiedad menos obvia: los parámetros de búsqueda desconocidos y los modificadores no admitidos deben rechazarse o notificarse, nunca descartarse silenciosamente. Un filtro que desaparece en silencio amplía una consulta, y una consulta ampliada sobre un registro de paciente es una divulgación. El mismo arnés de pruebas se ejecuta en CI como compuerta de fusión, de modo que una regresión aparece como un cambio de calificación en lugar de un incidente. Una afirmación de seguridad que se puede ejecutar vale más que una que solo se puede leer.

## Qué gana el paciente con esto

Volvamos al portapapeles. En CareAgents, la aplicación de consumo construida sobre esta capa, la solicitud es «Tengo cita con un médico nuevo la semana que viene, rellena mi formulario de admisión con mis registros.» El agente rellena el formulario usando SDC `$populate`, y entonces se detiene.

Cada medicamento y cada alergia requiere confirmación individual del paciente. «Sin alergias conocidas» requiere una attestation explícita y nunca se infiere de una lista vacía, porque una lista vacía y un negativo real son declaraciones clínicas diferentes. El servidor vuelve a derivar la lista de elementos en el momento del envío, de modo que una solicitud manipulada no puede saltarse ninguna fila. La aprobación genera un PDF con sello de procedencia detrás de un enlace firmado y con caducidad.

Once años de reescritura se convierten en revisar y aprobar. El agente hace el trabajo. El paciente conserva cada decisión. El servidor hace que esa división sea no negociable en lugar de una promesa en una política de privacidad.

## Por qué esta capa debe ser abierta

**Una propiedad de seguridad que no se puede inspeccionar es una afirmación de marketing.** Todos los proveedores dicen que su agente es seguro con PHI. El código abierto convierte eso en algo que el equipo de seguridad de un hospital puede leer, ejecutar y atacar. Eso es un tipo diferente de garantía y es el único que sobrevive a una revisión de seguridad.

**Los estándares de salud-IT se ganan con implementaciones de referencia abiertas.** FHIR se extendió porque HAPI, los servidores de prueba públicos, Synthea y los connectathons hicieron que la adopción fuera barata y la simulación difícil. La gobernanza de agentes se estandarizará de la misma manera o no lo hará en absoluto.

**El modelo de amenazas es mayor que cualquier equipo.** Inyección de prompts a través de documentos clínicos, fallos de aislamiento de inquilinos, parámetros de búsqueda descartados silenciosamente. Estos se encuentran con muchos lectores adversariales o no se encuentran. Publicamos los nuestros propios: un fallo de escritura de auditoría que revertía la transacción del llamante mientras devolvía éxito, y un input de inicio de sesión que truncaba códigos de 8 dígitos a 6. En un producto cerrado, esos son parches silenciosos. Aquí se convirtieron en pruebas de regresión.

**Una capa destinada a sobrevivir a todos los proveedores de modelos no debería pertenecer a ninguno.** Las APIs frontier y los modelos locales de pesos abiertos son cada vez más intercambiables detrás de un único adaptador. Lo que persiste a través de las generaciones de modelos es la capa de gobernanza. Si pertenece a un proveedor, las garantías del paciente expiran cuando cambia el modelo de negocio de ese proveedor.

## Lo que la comunidad debería hacer a continuación

Tres cosas, y ninguna de ellas es un producto.

**Escribir el perfil que falta.** Necesitamos una forma de expresar, en FHIR, lo que un lector puede hacer con un recurso después de recibirlo. No solo permiso para divulgar, sino retención, redivulgación, inferencia y entrenamiento. R6 `Permission` es el lugar adecuado para iniciar la conversación. Llévelo a los grupos de trabajo.

**Acordar un contrato de conformidad para el acceso de agentes.** Redactar, auditar, reforzar la autenticación, aprobar humanamente, aislar inquilinos, preservar la fidelidad de errores. Discuta esa lista. Sustitúyala por una mejor. Pero acuerde algo contra lo que un despliegue pueda ser calificado, para que «nuestro agente es seguro» deje de ser una frase infalsificable.

**Hacer que el paciente sea quien ostente la política.** Ahora mismo, la regla de redacción, el rastro de auditoría y la compuerta de aprobación pertenecen a quien escribió la aplicación. Eso es lo contrario de lo que debería ser para el intercambio dirigido por el consumidor, y solucionarlo es un problema de diseño que la comunidad no ha abordado seriamente.

Los datos de salud deberían ser fáciles de obtener. Esa batalla está en gran medida ganada. La siguiente es hacer que sea seguro actuar sobre ellos, con el paciente sosteniendo los controles en lugar de leer sobre ellos a posteriori.

HealthClaw Guardrails tiene licencia MIT y es lo suficientemente pequeño como para leerlo en una tarde: una fachada FHIR en Python, un servidor MCP en TypeScript, aproximadamente 1.170 pruebas en Python y 112 en Node, y el arnés de conformidad que condiciona el CI. Es una implementación de referencia y un argumento, no un producto. Si ejecuta Aidbox, clone el ejemplo e intente romperlo. Lo más útil que puede enviarnos es un payload que supere un control que no debería superar.

Ejemplo: [github.com/Aidbox/examples](https://github.com/Aidbox/examples/tree/main/aidbox-integrations/healthclaw-guardrails) · Repositorio: [github.com/aks129/HealthClawGuardrails](https://github.com/aks129/HealthClawGuardrails) · Conformidad en tiempo real: [app.healthclaw.io/r6/fhir/$conformance](https://app.healthclaw.io/r6/fhir/$conformance) · Aplicación de consumo: [careagents.cloud](https://careagents.cloud)

*Eugene Vestel escribe en FHIR IQ y presenta el podcast* Out of the FHIR*. Health Samurai desarrolla Aidbox, una plataforma FHIR para equipos de atención sanitaria.*