Primera línea con IA: playbook 30 días

Una primera línea con IA no se “enciende” un viernes: se diseña en 30 días alrededor de trabajos repetibles, límites clínicos, agenda real y handoff limpio. El objetivo no es reemplazar recepción; es dejar de perder citas por silencio, fuera de horario y confirmaciones manuales que nadie termina.

Por qué 30 días y no “un proyecto eterno”

La IPS promedio no necesita un programa de transformación de 18 meses para mejorar la primera línea. Necesita un piloto cerrado: un servicio, un canal, un conjunto de trabajos y un tablero. Si en 30 días no puedes demostrar citas confirmadas o cupos recuperados, no tienes un problema de “más tecnología”: tienes un problema de diseño.

La Ley 1438 de 2011 pone acceso, continuidad, oportunidad y calidad como ejes. Una primera línea con IA aporta cuando convierte demanda en acción dentro de esos ejes. La Resolución 3280 de 2018 exige rutas y seguimiento: el piloto debe dejar rastro, no solo audio o chats.

Este playbook asume una institución en Colombia que ya tiene agenda y un equipo humano de recepción o coordinación. No asume que “todo se automatiza”. Asume que lo repetible se cierra y lo sensible se escala. El veredicto de capa de contacto es el marco; aquí va el calendario.

Semana 0: elige el trabajo que duele

Antes del día 1, decide qué problema medible atacas. Ejemplos buenos:

• Confirmación de citas del día siguiente con alta no asistencia.
• Captura de demanda fuera de horario que hoy queda en buzón.
• Reprogramación simple dentro de reglas de sede.
• Recuperación de cupos liberados el mismo día.

Ejemplos malos para un primer mes:

• “Atender todas las especialidades con todas las excepciones.”
• “Reemplazar recepción presencial.”
• “Resolver PQRS complejas y juicio clínico.”
• “Integrar todo el universo de datos antes de hablar con nadie.”

La República reportó 91,9% de uso mensual de WhatsApp entre usuarios de internet mayores de 16 años en Colombia. Si tu dolor es confirmación, WhatsApp suele ser el canal principal del piloto. Si tu dolor es fuera de horario o ambigüedad, la voz puede ser mejor puerta de entrada. El mix de canales ayuda a decidir; no abras tres frentes a la vez.

Días 1–7: fronteras, dueños y datos mínimos

La primera semana no es “entrenar el modelo”. Es gobernar.

Día 1–2 — Fronteras negativas. Escribe lo que la IA no hará: no diagnostica, no interpreta estudios, no promete prioridad clínica, no inventa disponibilidad, no discute coberturas complejas, no pide datos sensibles de más. La Ley 1581 de 2012 obliga a tratar datos personales con propósito y control; el piloto debe decir qué dato captura, para qué y quién lo ve.

Día 3–4 — Dueños. Nombra roles, no áreas abstractas: quién aprueba guiones, quién recibe handoff, quién corrige agenda, quién revisa el tablero diario, quién detiene el piloto si aparece un incidente. Si el dueño es “recepción”, el piloto no tiene dueño. Si el dueño es una persona con nombre y un suplente, el piloto puede sobrevivir vacaciones y turnos.

Publica un mapa de una página: canal → trabajos → estados → escalamiento → tablero. Pévalo donde el equipo lo vea. La primera línea falla menos por falta de modelo que por falta de acuerdo visible.

Día 5–7 — Datos mínimos. Identidad, sede, servicio, estado de cita, canal, resultado de contacto, motivo de escalamiento. La Resolución 2275 de 2023 ordena el RIPS como soporte de la factura electrónica en salud y muestra cómo el dato de prestación deja de ser un apéndice informal. En primera línea, el equivalente operativo es simple: no captures basura que luego alguien tendrá que limpiar, y no inventes campos que la agenda no puede usar.

Días 8–14: integración mínima y handoff

La segunda semana conecta la conversación con la operación.

Necesitas, como mínimo:

1. Leer disponibilidad real o un subconjunto confiable de cupos del servicio piloto.
2. Escribir estados visibles para recepción: confirmó, canceló, reprogramó, no localizado, escalado.
3. Escalar con paquete (identidad, motivo, intentos, estado, decisión pedida).
4. Auditar qué se prometió.

Sin esos cuatro verbos, la IA es un megáfono. Con ellos, es primera línea. El detalle del paquete de transferencia está en handoff agente→humano: no improvises ese contrato el día del go-live.

Prueba en laboratorio:

• Persona que confirma sin fricción.
• Persona que cancela y libera cupo.
• Persona que pide reprogramar con dos opciones.
• Persona que describe un síntoma preocupante (debe escalar, no aconsejar).
• Persona que pide humano de inmediato.
• Fallo de agenda (mensaje honesto + tarea, no invención de cupo).

Documenta cada caso con el resultado esperado. Eso se vuelve tu batería de aceptación.

No subestimes la prueba del fallo. El día en que la agenda no responde, el equipo humano mirará si la IA inventa cupos o si declara el error con honestidad. Inventar es inaceptable. Declarar el error, dejar tarea y ofrecer callback es aceptable. Esa diferencia decide si el piloto genera confianza o incidentes.

También prueba el fuera de horario aunque tu piloto “sea diurno”. Simula un mensaje a las 21:00 y mira qué queda escrito al día siguiente. Si no hay estado, el aprendizaje del mes estará ciego a la demanda real.

Días 15–21: piloto controlado con personas reales

Tercera semana: volumen limitado, horario acotado, supervisión cercana.

Reglas del piloto controlado:

• Un servicio o un conjunto pequeño de agendas.
• Un canal principal.
• Horario declarado (por ejemplo, confirmaciones de 10:00 a 20:00).
• Revisión diaria de fallos, escalamientos y citas mal escritas.
• Botón de freno: quién puede pausar el canal en minutos.

No midas vanidad. Mide:

• Contactos intentados / efectivos
• Confirmaciones logradas
• Cancelaciones con cupo liberado
• Cupos rellenados el mismo día
• Escalaciones con paquete completo
• Incidentes de límite clínico (deben ser cero tolerados)

Habla con recepción todos los días. Si el equipo humano siente que la IA “deja basura”, el piloto ya falló aunque el demo se vea bien. Corrige estados y frases antes de subir volumen.

Un truco práctico de la tercera semana: reserva quince minutos al final del día para una “mesa de excepciones”. Lista solo los casos que no cerraron. Clasifícalos en regla faltante, dato incompleto, fallo técnico, límite clínico o error humano de recepción. Esa clasificación evita el debate eterno de “la IA no sirve” versus “el equipo no colabora”. Casi siempre hay de ambos, y cada clase tiene dueño distinto.

Si el volumen del piloto es demasiado bajo para aprender, amplía horarios antes de ampliar servicios. Si es demasiado alto para supervisar, recorta horarios antes de apagar el canal. El piloto controlado es un instrumento de aprendizaje, no una demostración de ego tecnológico.

Días 22–30: endurecer, medir y decidir escala

La última semana convierte el piloto en decisión.

La decisión go/no-go no es emocional. Usa umbrales acordados en semana 0. Ejemplo de lógica (ajusta a tu línea base):

• El piloto confirma mejor que el proceso manual en el mismo segmento.
• Los cupos liberados se ven a tiempo en agenda.
• Las escalaciones llegan con contexto y se cierran.
• Cero incidentes de consejo clínico indebido.
• Recepción reporta menos retrabajo, no más.

Si fallas un umbral crítico de seguridad, no “sigas afinando en producción”: pausa, corrige, reabre.

Guion, tono y excepciones: el trabajo invisible del mes

En paralelo al calendario técnico hay un trabajo editorial que muchas IPS subestiman. Quién escribe las frases de saludo, confirmación, cancelación, oferta de cupos y escalamiento. Quién aprueba el tono. Quién decide qué hacer cuando la persona habla de dolor, de embarazo, de un menor o de una queja contra la EPS. Ese trabajo no es “contenido de marketing”: es seguridad operativa.

Dedica bloques cortos en semanas 2 y 3 a revisar conversaciones reales (o simuladas) con el dueño clínico-administrativo del piloto. Busca tres fallas:

1. Promesas de más (“te atienden ya”, “es urgente”, “no te preocupes”).
2. Preguntas de más (datos sensibles innecesarios para agendar).
3. Silencios de más (cuando debió escalar y siguió charlando).

Corrige plantillas con ejemplos, no con principios abstractos. Una frontera clínica se entiende cuando se ve el caso. Guarda esos casos en una carpeta de regresión: cada vez que cambies el guion, vuelve a pasarlos. Sin regresión, el mes 2 reintroduce errores que el mes 1 ya había cerrado.

También define el vocabulario de estados. “Pendiente” es un estado inútil si no dice pendiente de qué y de quién. Prefiere estados accionables: pendiente de documento, pendiente de cupo, pendiente de callback a las 16:00, escalado a recepción, cerrado con cita confirmada. El tablero de gerencia se alimenta de esos estados; si el lenguaje es ambiguo, la decisión semanal también lo será.

Capacitación del equipo humano: sin esto el piloto se siente impuesto

La resistencia interna no se resuelve con un correo de “ahora tenemos IA”. Se resuelve mostrando qué trabajo se quita de encima y qué trabajo nuevo aparece. Recepción debe saber:

• Qué casos ya no debería estar confirmando a mano.
• Cómo leer el tablero de estados.
• Cómo recibir un handoff sin re-preguntar.
• Cuándo pausar o reportar un incidente.
• Qué métricas mirará gerencia (para que no sienta que “los van a medir por velocidad cruel”).

Haz una sesión de 45 minutos al inicio del piloto controlado y otra a mitad de la tercera semana. En la segunda, usa fallos reales anonimizados. El equipo confía más cuando ve que el diseño se corrige con su feedback. Si el feedback se ignora, el piloto muere por saboteo pasivo: estados mal cerrados, transferencias a destiempo, excepciones escondidas en chats privados.

Incluye a coordinación de agenda y a quien maneja cupos especiales. Una primera línea que ofrece horarios que el equipo luego invalida genera más latencia y más enojo que no tener automatización. La IA no puede ser más optimista que la agenda real.

Riesgos del día 30 y cómo no fingir éxito

Hay formas elegantes de mentirse al final del mes:

• Contar conversaciones en lugar de citas.
• Medir solo el segmento fácil y ocultar el fuera de horario.
• Declarar “éxito de adopción” porque el equipo ya no se queja en voz alta.
• Escalar a tres servicios nuevos para “aprovechar el momentum” sin dueño extra.

Evita esas trampas con un memo de una página: objetivo inicial, umbrales, resultado, incidentes, decisión, plan mes 2. Si no cabe en una página, aún no está claro. Gerencia no necesita un informe de transformación; necesita saber si la primera línea movió agenda con seguridad.

El playbook también debe decir qué no escalarás aunque el piloto “haya gustado”. Gustar no es un umbral. Citas confirmadas, cupos recuperados, escalaciones limpias y cero incidentes clínicos indebidos sí lo son.

Qué cambia en la operación cuando funciona

Cuando la primera línea con IA está bien montada, el cambio no es cosmético.

Eso es lo que una institución puede vender internamente al equipo: menos repetición, más juicio donde importa, mejor acceso. El mapa de /colombia/ recuerda el contexto de acceso; el playbook lo vuelve calendario.

Playbook resumido en pasos

1. 1
   Elige un trabajo medible

   Confirmación, captura fuera de horario, reprogramación simple o recuperación de cupos.

2. 2
   Escribe límites y dueños

   Qué no hace la IA, quién recibe handoff y quién puede frenar el canal.

3. 3
   Conecta leer / escribir / escalar / auditar

   Agenda real, estados compartidos, paquete de transferencia y registro.

4. 4
   Piloto controlado una semana

   Volumen limitado, revisión diaria y métricas de cita — no de vanidad.

5. 5
   Decide escala con umbrales

   Go solo si hay seguridad, menos retrabajo y citas movidas de verdad.

Una primera línea con IA bien hecha no se nota porque “habla bonito”. Se nota porque la agenda se mueve, el cupo no se pierde y el equipo humano deja de repetir lo mismo. Treinta días bastan para probarlo con disciplina. Sin disciplina, treinta días solo producen una demo cara.

El mes 2, si hay go, debe heredar la misma lógica: un solo trabajo nuevo o un solo servicio nuevo, nunca ambos. Ampliar WhatsApp y voz el mismo día sin dueño extra es la forma más rápida de destruir el aprendizaje del piloto. Ampliar tres especialidades porque “ya quedó bonito” es la segunda. El playbook existe para frenar ese impulso.

También deja por escrito el ritual semanal: quién mira el tablero el lunes, quién corrige guiones el miércoles, quién revisa incidentes el viernes. Sin ritual, la primera línea se degrada en silencio: frases viejas, estados ambiguos, handoffs incompletos. La IA no se mantiene sola; se opera.

Si tu institución está en Colombia y el acceso es el cuello de botella, este calendario es una forma concreta de responder. No sustituye red de servicios, ni capacidad clínica, ni financiación. Sustituye el vacío entre la persona que pide cita y el cupo que nadie le ofrece a tiempo.

Antes de cerrar el día 30, responde estas cinco preguntas en una sola página:

1. ¿Qué trabajo repetible quedó cerrado de punta a punta?
2. ¿Qué porcentaje de escalaciones llegó con paquete completo?
3. ¿Cuántos incidentes de límite clínico hubo y qué se cambió?
4. ¿Recepción reporta menos retrabajo o más limpieza de basura?
5. ¿Qué exactamente se escala en el mes 2, con qué dueño y qué umbral de freno?

Si no puedes responderlas, no tienes un playbook terminado: tienes una demo extendida. Vuélvela a correr con alcance más chico. Un piloto pequeño que mueve citas enseña más que un piloto amplio que solo genera conversaciones.

La primera línea con IA, bien gobernada, es infraestructura de acceso. Mal gobernada, es un nuevo canal de quejas. Elige el diseño que deja evidencia, no el que deja impresión.

En síntesis: treinta días no son para “implementar IA”. Son para demostrar, con seguridad y métricas de cita, que tu institución puede cerrar trabajo repetible sin romper lo sensible. Si lo demuestras, escala con método. Si no, aprendiste barato. Ambas salidas son mejores que un proyecto eterno sin veredicto.