Definir el terreno: IA administrativa, no decisión clínica
Una clínica no necesita empezar su evaluación de inteligencia artificial por una demostración de producto. Necesita partir de la operación que sostiene el servicio: admisión, coordinación de documentos, derivaciones administrativas, cuentas por cobrar, abastecimiento, reportes internos y seguimiento de tareas. Son frentes donde hay información repetida, responsables definidos y decisiones que pueden describirse como reglas. El objetivo no es delegar juicio profesional a un sistema; es reducir fricción en actividades administrativas y hacer visible dónde se detiene un caso.
Esa separación debe constar desde el inicio. Si una solicitud contiene síntomas, resultados, indicaciones o cualquier asunto que requiera valoración sanitaria, el flujo administrativo debe detenerse y derivar al protocolo humano correspondiente. La evaluación que sigue se concentra en trabajo de soporte: clasificar solicitudes por área, preparar borradores internos, verificar que un expediente tenga los campos requeridos, resumir incidencias para revisión y coordinar tareas. Así se evita presentar un proyecto de operación como si fuera una herramienta de atención clínica.
Construir un portafolio antes de escoger una herramienta
El primer entregable útil es un inventario de casos, no una lista de proveedores. Cada área puede aportar situaciones concretas: registrar solicitudes recibidas por distintos canales, ordenar comprobantes para revisión, conciliar datos entre registros administrativos, extraer campos de documentos, preparar un estado de trámite o alertar sobre una tarea vencida. Conviene describir el inicio, el resultado esperado, las personas que intervienen, los sistemas involucrados y la excepción que obliga a una revisión humana.
El portafolio también ayuda a descartar propuestas prematuras. Un caso no está listo sólo porque parece repetitivo. Si cambia cada día, depende de un criterio que nadie ha documentado o utiliza información a la que el equipo no tiene acceso legítimo, todavía es un problema de proceso, definición o gobierno. Documentarlo como “no priorizable por ahora” es una decisión válida: evita convertir una prueba técnica en un proyecto que aumenta la carga del equipo.
Priorizar por riesgo, viabilidad y valor operativo
Para ordenar el portafolio, una clínica puede evaluar cada caso con tres preguntas. Primero: ¿qué ocurre si la salida es incompleta o errónea y quién puede detectarlo antes de actuar? Segundo: ¿el flujo tiene entradas, reglas, responsable y resultado observables? Tercero: ¿qué carga administrativa o demora busca reducir? La prioridad no debe depender de una promesa genérica de ahorro, sino de la combinación entre impacto operativo, posibilidad real de implementar controles y consecuencia de un error.
Los casos de menor riesgo y mayor viabilidad suelen permitir una primera experiencia controlada: organizar una cola interna, identificar expedientes incompletos para revisión, convertir un formulario en tareas o elaborar un resumen que una persona valida. En cambio, una propuesta que modifica registros sin revisión, reúne información sensible sin controles claros o exige integrar varios sistemas desconocidos debe pasar a una etapa de preparación. La matriz sirve para hacer explícito por qué se inicia, se posterga o se descarta cada caso.
Comprobar la readiness de datos y procesos
La viabilidad depende de la calidad operativa de los datos, no sólo de que existan archivos. Antes de un piloto hay que identificar qué datos entran, de dónde salen, qué campos son necesarios, quién es responsable de mantenerlos y cómo se reconocerá una inconsistencia. También importa saber si hay identificadores duplicados, versiones contradictorias, documentos escaneados sin estructura o planillas que sólo una persona comprende. Estas condiciones no impiden toda automatización, pero delimitan qué caso puede abordarse con seguridad.
La preparación incluye revisar acceso y trazabilidad. El equipo debe poder explicar qué información consulta el flujo, para qué fin, dónde queda la salida y cuánto tiempo se conserva. Cuando un caso requiere datos personales o información de salud, la clínica debe involucrar a quienes tienen responsabilidad sobre privacidad, seguridad y operación antes de habilitarlo. La Ley N.º 29733 es una fuente primaria para revisar el marco peruano de protección de datos; su lectura no sustituye la evaluación específica que corresponda a la organización.
Evaluar opciones con evidencia del flujo real
Una evaluación responsable compara alternativas contra un conjunto de escenarios propios, no contra una presentación comercial. Para cada caso priorizado se pueden preparar ejemplos representativos, incluyendo una entrada completa, una ambigua, una incompleta y una que deba escalarse. Se revisa si la herramienta conserva el contexto necesario, si permite corrección humana, si registra las acciones y si sus permisos se ajustan a los roles existentes. La evidencia útil es el comportamiento frente al proceso real, no una respuesta convincente en un caso ideal.
La evaluación debe dejar por escrito sus límites. Conviene registrar qué tareas no cubre la opción, qué integración no está demostrada, qué datos no se usarán y quién acepta la salida antes de que llegue a un sistema de operación. Si un proveedor declara una capacidad, la clínica puede pedir que se pruebe con una condición de su propio flujo. Este enfoque permite separar una función demostrada de una expectativa, y evita fijar métricas o resultados que aún no se han observado.
Asignar gobierno, permisos y controles de seguridad
El gobierno empieza por una asignación simple de responsabilidades. Debe existir un dueño del proceso, una persona responsable de la configuración, un revisor de las salidas y un canal para reportar incidentes. Para cada automatización se documentan propósito, alcance, fuentes de datos, roles con acceso, puntos de intervención humana y procedimiento de suspensión. Sin esa base, una corrección termina siendo una conversación informal y nadie puede reconstruir por qué se tomó una acción.
La seguridad se diseña alrededor del mínimo acceso necesario. Separar ambientes de prueba y operación, usar cuentas individuales, limitar permisos por rol y conservar registros de cambios son controles prácticos que deben evaluarse según el contexto técnico. Asimismo, el equipo necesita saber qué hacer ante una salida errónea, un acceso no esperado o un dato que no debería haberse utilizado: detener el flujo, preservar evidencia, informar al responsable y seguir el procedimiento interno. NIST AI RMF ofrece una referencia primaria para estructurar la gestión de riesgos de IA, sin reemplazar las obligaciones locales ni la política de la clínica.
Diseñar un piloto acotado y revisable
Un piloto no es una puesta en producción reducida; es una prueba con hipótesis, límites y fecha de revisión. Debe definir una población de trabajo delimitada, el equipo que participa, las entradas permitidas, la salida esperada y el punto donde una persona valida antes de ejecutar una acción relevante. También debe contemplar ejemplos de excepción: información faltante, una solicitud fuera de alcance, una discrepancia entre sistemas o una respuesta que no alcanza el estándar del área.
En lugar de prometer un porcentaje de mejora, el piloto puede observar criterios verificables: si la salida contiene los campos requeridos, si llega al responsable correcto, si las excepciones se escalan, si el equipo puede corregirla y si quedan registros suficientes para revisarla. La comparación debe hacerse contra el proceso previo documentado y durante un periodo acordado por la clínica. El resultado puede ser continuar, ajustar, pausar o retirar el caso; cualquiera de esas decisiones aporta evidencia para el portafolio.
Decidir la escala con criterios explícitos
Escalar no consiste en añadir más áreas porque una demostración funcionó. Antes de ampliar, la clínica debe revisar si el piloto mantuvo los controles acordados, si el responsable puede operar el flujo sin dependencia excepcional, si las correcciones se registran y si la integración tiene un mecanismo de soporte. También debe confirmar que el alcance nuevo no introduce datos, roles o consecuencias que el piloto no evaluó. Cada ampliación merece una evaluación proporcional a su riesgo.
Los criterios de escala deben incluir condiciones para no avanzar: fallas repetidas sin corrección, accesos que no pueden justificarse, ausencia de revisión humana donde era necesaria o imposibilidad de reconstruir una salida. Mantener esos criterios por escrito protege al equipo frente a la presión de convertir una prueba en operación permanente. La Organización Mundial de la Salud publica principios y consideraciones sobre ética y gobernanza de IA para la salud que pueden orientar la discusión de responsabilidades; la clínica debe aterrizarlos a sus procesos, controles y decisiones administrativas concretas.
