IA en todo: cuando las etiquetas fueron más ridículas que las funciones

Cuando las etiquetas van por delante de las funciones

“IA” solía significar que tenías un modelo, lo entrenabas, lo desplegabas y pasabas el siguiente año aprendiendo qué se siente la deriva en tu rotación on-call. Ahora “IA” puede significar cualquiera de estos casos:

• Un motor de reglas codificado con una nueva frase de marketing.
• Una llamada a la API de un proveedor donde no controlas el comportamiento del modelo, la retención de datos ni el ritmo de lanzamientos.
• Un modelo alojado localmente con una factura de GPU y un problema de colas.
• Una función que antes era determinista y ahora tiene una puntuación de confianza y un encogimiento de hombros.

Las etiquetas importan porque cambian la toma de decisiones. Una vez que algo se etiqueta como “IA”, los equipos aceptan modos de fallo que nunca aceptarían en otro contexto: no determinismo, corrección parcial, regresiones súbitas por cambios aguas arriba y salidas que no pueden explicarse fácilmente a auditores o clientes.

Y “IA en todo” tiende a crear una patología organizativa específica: dejas de preguntar qué hace la función y comienzas a preguntar qué te compra la etiqueta. Así terminas con tostadoras con IA. O, más comúnmente, con enrutamiento de tickets “con IA” que cuesta más que los humanos que reemplazó y enruta peor cuando importa.

Esta es la postura operativa que te mantiene empleado: trata la “IA” como un detalle de implementación, no como una categoría de producto. Exige el mismo rigor que exiges de cualquier dependencia crítica: SLOs explícitos, criterios de aceptación verificables, planes de rollback, techos de coste y controles de seguridad.

Una cita para llevar en el bolsillo, porque nunca deja de ser cierta: “La esperanza no es una estrategia.” — Rick Page.

Por qué la etiqueta es peligrosa

Es peligrosa porque invita a la vaguedad. En el momento en que alguien dice “el modelo lo resolverá”, deberías oír: “no hemos especificado requisitos y estamos externalizando nuestro pensamiento a la probabilidad”. Eso puede estar bien para el autocompletado. No está bien para una tubería de facturación.

La mayoría de las “funciones IA” fallan por razones aburridas:

• Son más lentas que el flujo existente, así que los usuarios las abandonan.
• Fallas bajo carga, así que los equipos de soporte aprenden a deshabilitarlas.
• Son caras a escala, así que finanzas se convierte en tu detonante de outage.
• Son inseguras en casos extremos, así que legal te hace envolverlas en exenciones hasta que sean inútiles.

Broma #1: La llamamos “potenciada por IA” hasta el primer incidente, cuando pasó a ser “temporalmente basada en reglas por estabilidad”.

Qué significa “función real” en producción

Una función real tiene:

• Entradas que puedes enumerar y validar.
• Salidas que puedes puntuar, acotar y explicar.
• Rendimiento que puedes predecir bajo carga.
• Plan de fallback que preserva el recorrido del usuario.
• Telemetría que te diga si está ayudando o perjudicando.

“IA” no elimina esas necesidades. Las multiplica. Ahora tienes un componente estocástico cuyos modos de fallo pueden ser sutiles: devuelve algo, pero no algo útil, y lo hace con confianza. Eso no es un 500. Es corrupción silenciosa de datos en lenguaje humano.

Hechos y contexto histórico que importan en ops

La gente trata el momento actual de “IA en todas partes” como sin precedentes. No lo es. La tecnología es relativamente nueva; el ciclo de hype es clásico. Algunos hechos concretos te ayudan a argumentar con confianza en salas que prefieren eslóganes:

1. El término “inteligencia artificial” se acuñó en 1956 en el taller de Dartmouth. El branding fue ambicioso desde el primer día, mucho antes de que existieran sistemas en producción para juzgarlo.
2. La IA ha tenido múltiples “inviernos” (notablemente en los 70 y finales de los 80/principios de los 90) cuando la financiación colapsó tras promesas infladas que no se cumplieron. El hype es cíclico; la deuda operativa es permanente.
3. Los sistemas expertos dominaron la IA empresarial en los 80: reglas, bases de conocimiento y mantenimiento frágil. El “prompt engineering como lógica de negocio” de hoy es inquietantemente similar—solo que con más tokens y menos garantías.
4. El resurgimiento moderno del backpropagation en 1986 (Rumelhart, Hinton, Williams) recuerda que los avances pueden permanecer hasta que el cómputo y los datos los hagan prácticos. La practicidad es una restricción de ops, no una cuestión filosófica.
5. El momento ImageNet de 2012 (deep learning superando métodos anteriores de visión) tuvo tanto que ver con GPUs y datasets como con algoritmos. Tu “función IA” probablemente es una historia de cadena de suministro: chips, ancho de banda, almacenamiento y uptime del proveedor.
6. Los Transformers (2017) hicieron escalables los modelos de lenguaje grandes, pero también convirtieron el coste y la latencia de inferencia en una restricción de producto de primera clase. Si no puedes permitirte p99, no tienes una función.
7. El rendimiento del modelo no es monótono en el tiempo. Los modelos desplegados pueden empeorar a medida que cambia el comportamiento de los usuarios, el lenguaje se desplaza, la estacionalidad aparece o los pipelines de datos upstream derivan. El software tradicional rara vez se pudre así.
8. La regulación de la “IA” se está acelerando en varias jurisdicciones, lo que significa que la procedencia, la explicabilidad y los registros de auditoría no son “extras empresariales” ya; son requisitos básicos en entornos con gestión de riesgo.

Un marco de decisión: qué lanzar, qué prohibir, qué medir

Empieza con la única pregunta que importa: ¿qué problema estamos resolviendo?

No “cómo añadimos IA”. La declaración del problema debe ser legible sin las letras I y A. Ejemplo:

• Bueno: “Reducir el tiempo medio de resolución resumiendo cronologías de incidentes desde logs y tickets”.
• Malo: “Añadir un asistente IA al NOC”.

Si no puedes escribir criterios de éxito como una prueba, estás a punto de lanzar una demo. Las demos están bien. Pertenecen a sandboxes con interruptores de apagado rígidos.

Define la clase de tu función: determinista, probabilística o consultiva

La mayoría de los incidentes en producción ocurren porque los equipos despliegan un sistema probabilístico como si fuera determinista. Decide qué estás construyendo:

• Función determinista: la misma entrada produce la misma salida. Puedes cachear. Puedes razonar sobre ella. Genial.
• Función probabilística: las salidas varían, la confianza importa y la corrección es estadística. Necesita puntuación, monitorización y guardarraíles.
• Función consultiva: el sistema sugiere; un humano o una puerta determinista decide. Aquí debería vivir la mayoría de la “IA en todo” hasta que se demuestre segura.

Hazlo medible: lanza con una “métrica de resultado” y una “métrica de daño”

Las métricas de resultado responden “¿esto ayuda?”. Las métricas de daño responden “¿qué se rompe cuando está mal?”. Necesitas ambas.

• Ejemplos de resultado: tasa de desvío (soporte), tiempo de finalización (flujo de trabajo), incremento de conversión (comercio), tiempo ahorrado por ticket (ops).
• Ejemplos de daño: reembolsos incorrectos, tickets de alta severidad mal enrutados, violaciones de políticas, filtración de PII, pérdida de clientes por respuestas absurdas.

Luego añade restricciones:

• Presupuesto de latencia: objetivos p50/p95/p99.
• Presupuesto de errores: umbrales de disponibilidad y corrección.
• Presupuesto de coste: coste por petición y techo mensual con alertas.

Arquitecta para el fallo, no para las sensaciones

“IA en todo” suele significar “nueva dependencia de red en todo”. Así obtienes fallos en cascada. Trata el componente IA como un upstream poco fiable:

• Timeouts con valores sensatos (más cortos de lo que piensas).
• Circuit breakers para soltar carga.
• Modo de fallback que preserve la funcionalidad central.
• Bulkheads: aisla la función IA para que no pueda dejar sin recursos al resto del sistema.
• Solicitudes reproducibles para evaluación offline y análisis post-incidente.

Broma #2: Nuestra “hoja de ruta IA” fue tan agresiva que tuvimos que añadir un nuevo nivel a la taxonomía de incidentes: “Sev-2, pero filosófico”.

No confundas “ingenioso” con “fiable”

A los equipos les encanta lo ingenioso. A los usuarios les encanta lo fiable. A los ejecutivos les importan los números trimestrales. Tu trabajo es entregar los tres poniendo la fiabilidad por delante de la novedad. La forma más fácil: exige que cada función IA tenga un fallback no-IA que cumpla la UX mínima. Si el fallback resulta humillante, bien—ahora sabes qué significa “mínimo” realmente.

Tres micro-relatos corporativos desde las trincheras

Micro-relato #1: El incidente causado por una suposición errónea

En una empresa B2B SaaS mediana, la dirección de soporte quería “triage de tickets con IA”. La propuesta era clara: ingerir correos entrantes, clasificar la intención, enrutar a la cola correcta, autoetiquetar prioridad y reducir el tiempo de respuesta. La demo del proveedor se veía genial. La integración se activó detrás de un feature flag. Todos se felicitaron por ser modernos.

La suposición errónea fue sutil: el equipo asumió que la clasificación del modelo era “como un motor de reglas, pero más inteligente”. En otras palabras, estable. No construyeron monitorización explícita de deriva ni fallbacks robustos porque la función no era “camino crítico”… hasta que silenciosamente se volvió camino crítico. Los agentes de soporte dejaron de triagear manualmente porque el nuevo sistema era más rápido, y los gerentes empezaron a medirlos asumiendo que el enrutamiento era correcto.

Entonces un lanzamiento de producto cambió el lenguaje de los clientes. La gente empezó a usar términos nuevos que eran cercanos a los viejos pero no idénticos. El modelo empezó a enrutar “disputa de facturación” a “solicitud de función”. El primer síntoma no fue un 500; fue un cliente que recibió una respuesta optimista sobre la hoja de ruta del producto a una solicitud de reembolso. El cliente escaló. Luego lo hicieron unos cuantos más.

Operaciones se involucró después. Los logs mostraban que el sistema estaba “saludable”. Latencia bien. Tasa de errores bien. El incidente fue degradación de corrección. Una vez que muestrearon los errores de enrutamiento, la falla fue obvia, pero tomó días porque no había un bucle de retroalimentación de “verdad en tierra” y no había comparación de línea base. La solución no fue glamorosa: forzar a los agentes a confirmar el enrutamiento (modo consultivo), almacenar resultados etiquetados, reentrenar y evaluar semanalmente, y añadir alarmas de deriva basadas en cambios en la distribución de etiquetas.

La lección real: los sistemas probabilísticos necesitan telemetría explícita de corrección. “No hay errores en los logs” no significa nada cuando el sistema está incorrecto de forma educada.

Micro-relato #2: La optimización que salió mal

Una plataforma minorista añadió un “mejorador de descripciones de producto” basado en LLM. Tomaba texto del proveedor y lo limpiaba para consistencia. La versión inicial funcionaba de forma asíncrona y escribía resultados en una caché. Era lenta pero segura: si el job fallaba, el texto antiguo permanecía. Luego marketing lo quiso “en tiempo real” en el editor de producto para que los humanos pudieran ver la magia.

El plan de optimización parecía razonable: cachear prompts y reutilizar resultados; aumentar concurrencia; reducir timeouts para que la UI no se quedara colgada. También añadieron un segundo modelo como fallback. Midieron p50 y declararon victoria.

Lo que se perdieron fue el p99 durante el pico de uso del editor. Cuando la concurrencia se disparó, la API upstream empezó a aplicar rate limiting. El sistema entró en reintentos. Los reintentos amplificaron la carga. El modelo de fallback se activó y devolvió estilos distintos. Los usuarios empezaron a guardar borradores con tono inconsistente y, peor, ocasionalmente con especificaciones inventadas. El sistema no estaba “caído”, estaba “errático”.

Los costes se dispararon porque la tormenta de reintentos incrementó el uso de tokens. Finanzas lo notó antes que ingeniería. El fiasco fue perfecto: peor UX, mayor coste y backlog de soporte porque los proveedores se quejaban de ediciones incorrectas.

La solución fue disciplina SRE clásica: limitar concurrencia, implementar backoff exponencial con jitter y presupuestos de reintento duros, pasar la generación de nuevo a asincrónico con una UX explícita de “borrador listo” y añadir una capa de validación que compruebe las salidas contra atributos de producto estructurados (dimensiones, materiales) antes de aceptarlas. También empezaron a monitorizar respuestas de rate-limit como un SLI de primera clase.

Micro-relato #3: La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros desplegó un “asistente IA” interno para analistas. Respondía preguntas utilizando un sistema de recuperación sobre políticas e informes previos. La revisión de riesgo inicial fue tensa: fuga de datos, alucinaciones, cumplimiento. El equipo hizo algo poco glamoroso: construyó un arnés de evaluación exhaustivo antes del despliegue amplio.

Crearon un conjunto de pruebas fijo de consultas con citas esperadas. Cada cambio de modelo o prompt debía pasar: la respuesta debe incluir citas; las citas deben mapear a documentos aprobados; no debe haber PII en la salida; latencia bajo un presupuesto. También implementaron registro de solicitudes con redacción y almacenaron los IDs de los documentos recuperados junto a la respuesta para auditoría.

Dos meses después, el proveedor de modelo upstream cambió comportamiento. No “downtime”, solo formato de salida distinto y una ligera tendencia a generalizar diferente. El arnés lo detectó el mismo día porque la adherencia de citas cayó. El equipo congeló el despliegue, fijó la versión del modelo donde fue posible y usó el modo de respuesta fallback (“Aquí están los documentos; sin respuesta sintetizada”) hasta poder revalidar.

Sin incidente, sin escalada ejecutiva, sin pánico de cumplimiento. Las puertas aburridas hicieron lo que hacen las puertas aburridas: prevenir outages emocionantes.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Esta es la versión “on-call a las 2 a.m.”. No necesitas una filosofía de IA. Necesitas un culpable.

Primero: ¿es el modelo, la red o tu sistema?

1. Revisa los síntomas visibles para el usuario: ¿es lento, está equivocado o está fallando? Lo lento y lo fallido es más fácil que lo equivocado.
2. Revisa la salud de las dependencias: límites de tasa de la API LLM, timeouts, DNS, TLS, egress saliente, estado del proveedor (si lo tienes).
3. Revisa la saturación de tus propios recursos: CPU, memoria, utilización de GPU, profundidad de colas, pools de hilos, pools de conexiones.

Segundo: identifica qué etapa domina

La mayoría de las funciones IA son una tubería:

• Parseo de la petición + auth
• Construcción de prompt o extracción de features
• Recuperación (búsqueda vectorial / fetch de base de datos)
• Inferencia (API remota o modelo local)
• Post-procesado (validación, formateo, controles de política)
• Escritura/cacheo

Mide el tiempo de cada etapa. Si no puedes, añade instrumentación antes de añadir más “IA”.

Tercero: detén la hemorragia

• Habilita el modo fallback (sin generación, solo recuperación, respuestas en caché o desactivar el feature flag).
• Reduce la concurrencia y aplica timeouts.
• Apaga reintentos que no tengan presupuesto.
• Aplica rate limiting en el borde; protege servicios centrales con bulkheads.

Cuarto: decide si tienes un incidente de corrección

Si los usuarios reportan “está dando malas respuestas”, trátalo como corrupción de datos: muestrea, reproduce, encuentra un patrón común y detén el despliegue. Los incidentes de corrección no aparecen en los gráficos de CPU.

Tareas prácticas con comandos: evidencia sobre sensaciones

Estas tareas están sesgadas hacia servidores Linux que ejecutan un servicio adyacente a IA (pipeline RAG, búsqueda vectorial, gateway de modelos o un servidor de inferencia alojado localmente). Para cada una: comando, qué significa la salida y qué decisión tomas.

Tarea 1: Confirma la salud básica del servicio y la tasa de errores (systemd + logs)

cr0x@server:~$ systemctl status ai-gateway --no-pager
● ai-gateway.service - AI Gateway
     Loaded: loaded (/etc/systemd/system/ai-gateway.service; enabled)
     Active: active (running) since Mon 2026-01-22 08:11:02 UTC; 3h 12min ago
   Main PID: 2147 (ai-gateway)
      Tasks: 38
     Memory: 612.3M
        CPU: 1h 44min

Significado: El proceso está arriba; memoria y CPU son visibles. Esto no prueba la corrección ni la salud upstream.

Decisión: Si no está active/running, reinicia e investiga crash loops. Si está en ejecución, pasa a chequear latencia y dependencias.

cr0x@server:~$ journalctl -u ai-gateway -n 50 --no-pager
Jan 22 11:12:55 server ai-gateway[2147]: WARN upstream timeout model=vendor-llm request_id=9c2a...
Jan 22 11:12:55 server ai-gateway[2147]: WARN retrying attempt=2 backoff_ms=400
Jan 22 11:12:56 server ai-gateway[2147]: ERROR upstream rate_limited model=vendor-llm status=429

Significado: No estás “down”. Te están limitando y hay timeouts. Los reintentos empeoran activamente la situación.

Decisión: Reduce concurrencia, aplica presupuestos de reintento, considera cambiar a modo fallback.

Tarea 2: Mide p50/p95/p99 de latencia en el borde (logs de nginx)

cr0x@server:~$ awk '{print $NF}' /var/log/nginx/access.log | tail -n 2000 | sort -n | awk 'NR==1000{p50=$1} NR==1900{p95=$1} NR==1980{p99=$1} END{print "p50="p50,"p95="p95,"p99="p99}'
p50=0.842 p95=6.913 p99=18.402

Significado: La mediana parece bien; la cola tiene una latencia brutal. Normalmente es contención upstream, rate limiting o colas.

Decisión: Persigue las causas de la cola: timeouts, saturación, pools de conexión, consultas de recuperación lentas o profundidad de cola del modelo.

Tarea 3: Verifica que DNS y TLS no sean tu “problema IA”

cr0x@server:~$ dig +time=2 +tries=1 api.vendor-llm.internal A | sed -n '1,12p'
; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 api.vendor-llm.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
api.vendor-llm.internal. 30 IN A 10.20.30.40

Significado: DNS resuelve rápido y correctamente aquí.

Decisión: Si DNS es lento o falla, arregla resolvers/caching antes de culpar al modelo. Si está bien, prueba conectividad y TLS.

cr0x@server:~$ openssl s_client -connect api.vendor-llm.internal:443 -servername api.vendor-llm.internal -brief < /dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = api.vendor-llm.internal
Verification: OK

Significado: El handshake TLS tiene éxito; el certificado verifica. Si esto falla de forma intermitente, tu “outage IA” podría ser una rotación PKI o problemas de MTU.

Decisión: Si el handshake es lento/falla, investiga el path de red, proxies o despliegue de certificados.

Tarea 4: Comprueba límites de tasa y mezcla de errores upstream (curl)

cr0x@server:~$ curl -s -D - -o /dev/null -m 10 https://api.vendor-llm.internal/v1/models
HTTP/2 200
date: Mon, 22 Jan 2026 11:18:02 GMT
x-ratelimit-limit-requests: 3000
x-ratelimit-remaining-requests: 12
x-ratelimit-reset-seconds: 23

Significado: Estás cerca del precipicio. Remaining requests es bajo; reset es pronto.

Decisión: Añade throttling y colas del lado cliente. Si no puedes, habilita caché o degrada con gracia.

Tarea 5: Comprueba si tu propia cola es el cuello de botella (Linux socket backlog + proxy de métricas)

cr0x@server:~$ ss -lntp | awk 'NR==1 || /:8080/'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 512    4096   0.0.0.0:8080      0.0.0.0:*     users:(("ai-gateway",pid=2147,fd=12))

Significado: Un Recv-Q alto en relación al tráfico esperado sugiere que la app no acepta lo suficientemente rápido o está bloqueada.

Decisión: Si Recv-Q sube durante incidentes, perfila pools de hilos, pausas de GC o esperas downstream.

Tarea 6: Identifica saturación de CPU y presión de run queue

cr0x@server:~$ uptime
 11:19:44 up  3:22,  2 users,  load average: 18.42, 16.90, 15.77

Significado: Los promedios de carga son altos. En máquinas con pocos cores, estás saturado de CPU o bloqueado en I/O con muchas tareas ejecutables.

Decisión: Comprueba el recuento de cores y luego usa vmstat/top para decidir si es CPU o espera de I/O.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0  48212  21032 611204    0    0    10    24 1520 4820 78 12 10  0  0
15  0      0  47680  21032 611420    0    0    12    16 1602 5011 81 11  8  0  0

Significado: Alto r con bajo wa implica presión de CPU, no espera de disco.

Decisión: Escala horizontal, reduce concurrencia u optimiza los caminos calientes (construcción de prompts, parseo JSON, criptografía, compresión).

Tarea 7: Encuentra el proceso caro y sus hilos (top)

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 11:20:31 up  3:23,  2 users,  load average: 19.02, 17.10, 15.92
Tasks: 238 total,  15 running, 223 sleeping,   0 stopped,   0 zombie
%Cpu(s): 84.5 us, 11.2 sy,  0.0 ni,  4.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  15928.0 total,    121.4 free,   1912.5 used,  13894.1 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2147 app      20   0 3248216 612340  48212 R  720.1   3.8  105:12.33 ai-gateway

Significado: El gateway consume CPU a través de muchos cores. Suele ser serialización, tokenización, cifrado o scoring de recuperación.

Decisión: Perfila; considera mover trabajo pesado fuera del path de petición; implementa caché; reduce la verbosidad de logs.

Tarea 8: Comprueba presión de memoria y si estás haciendo swap

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15928        1897         118          42       13912       13640
Swap:              0           0           0

Significado: Poco “free” no es problema por sí mismo; “available” está sano. No hay swap configurado.

Decisión: Probablemente la memoria no es el cuello de botella. Si available colapsa o aparece OOM, ajusta caches o fija límites.

Tarea 9: Si alojas modelos, verifica utilización de GPU y margen de memoria

cr0x@server:~$ nvidia-smi
Wed Jan 22 11:22:06 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  NVIDIA A10G                    On   | 00000000:00:1E.0 Off |                    0 |
|  0%   61C    P0              142W / 150W|  22340MiB / 24564MiB |     98%      Default |
+-----------------------------------------+----------------------+----------------------+

Significado: GPU está al máximo y la memoria casi llena. La latencia de cola se disparará cuando se acumulen peticiones.

Decisión: Reduce tamaños de batch, aumenta réplicas, cambia a un modelo más pequeño o externaliza picos a un proveedor.

Tarea 10: Confirma latencia y saturación de disco (los índices vectoriales suelen doler)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server)  01/22/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          32.10    0.00    6.22    9.84    0.00   51.84

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1        842.0  91320.0     12.0    1.4   14.82   108.4    112.0   1840.0    3.11   8.92   92.6

Significado: Alta carga de lectura y alto r_await con ~93% de util indica que el almacenamiento es un cuello de botella (a menudo escaneos de índices de recuperación o compactaciones).

Decisión: Optimiza la búsqueda vectorial (parámetros HNSW, caché), aumenta RAM para índices calientes, mueve índices a NVMe más rápidos o divide shards.

Tarea 11: Comprueba espacio de sistema de archivos y agotamiento de inodos (el asesino silencioso)

cr0x@server:~$ df -h /var/lib/vector
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  900G  874G   26G  98% /var/lib/vector

Significado: Estás al 98% de uso. Muchas bases de datos y constructores de índices funcionan muy mal cuando el disco está casi lleno.

Decisión: Libera espacio inmediatamente; detén compactaciones; expande el volumen; aplica políticas de retención.

cr0x@server:~$ df -i /var/lib/vector
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/nvme0n1p2  58982400 58611210   371190  99% /var/lib/vector

Significado: Los inodos están agotados. Puedes tener espacio pero fallar al crear archivos.

Decisión: Reduce churn de archivos pequeños (número de segmentos, rotación de logs), reformatea con más inodos si es necesario o consolida el layout de almacenamiento.

Tarea 12: Valida que tu caché realmente funcione (ejemplo Redis)

cr0x@server:~$ redis-cli INFO stats | egrep 'keyspace_hits|keyspace_misses|evicted_keys'
keyspace_hits:1829441
keyspace_misses:921332
evicted_keys:44120

Significado: Los misses son altos y hay expulsiones. Estás golpeando la caché, lo que probablemente aumenta llamadas LLM upstream y coste.

Decisión: Aumenta tamaño de caché, corrige TTLs, normaliza claves de caché y cachea resultados de recuperación (no solo respuestas finales).

Tarea 13: Detecta tormentas de reintentos vía logs de peticiones (grep + counts)

cr0x@server:~$ grep -c "retrying attempt" /var/log/ai-gateway/app.log
18422

Significado: Reintentos son comunes; durante un incidente este número subirá bruscamente.

Decisión: Aplica un presupuesto de reintentos por petición, añade jitter y evita reintentos en 429 salvo que haya un Retry-After.

Tarea 14: Comprueba si el uso de tokens (proxy de coste) se está disparando

cr0x@server:~$ awk '/tokens_in=/{for(i=1;i<=NF;i++) if($i ~ /tokens_in=/){split($i,a,"="); in+=a[2]} if($i ~ /tokens_out=/){split($i,b,"="); out+=b[2]}} END{print "tokens_in="in, "tokens_out="out}' /var/log/ai-gateway/app.log
tokens_in=9284410 tokens_out=16422033

Significado: Los tokens de salida exceden dramáticamente los de entrada. Puede estar bien para resúmenes; es terrible para funciones de “respuesta corta”.

Decisión: Ajusta max tokens, fuerza formatos concisos e introduce secuencias de parada o salida estructurada.

Tarea 15: Valida latencia de consultas DB vectorial (ejemplo PostgreSQL + pgvector)

cr0x@server:~$ psql -d rag -c "EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM docs ORDER BY embedding <-> '[0.1,0.2,0.3]' LIMIT 5;"
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..1.05 rows=5 width=8) (actual time=42.118..42.140 rows=5 loops=1)
   Buffers: shared hit=120 read=980
   ->  Index Scan using docs_embedding_hnsw on docs  (cost=0.42..1200.00 rows=10000 width=8) (actual time=42.116..42.136 rows=5 loops=1)
 Planning Time: 0.312 ms
 Execution Time: 42.202 ms

Significado: 42 ms puede estar bien, pero nota las altas lecturas de disco. Bajo carga esto se convierte en latencia cola.

Decisión: Aumenta shared buffers, calienta el índice, mejora la localidad (menos shards por nodo) o ajusta parámetros de índice para intercambiar precisión por velocidad.

Tarea 16: Confirma que el kernel/camino de red no esté perdiendo paquetes (ss + retrans)

cr0x@server:~$ ss -ti dst api.vendor-llm.internal | sed -n '1,20p'
ESTAB 0 0 10.0.1.10:51244 10.20.30.40:https users:(("ai-gateway",pid=2147,fd=33))
	 cubic wscale:7,7 rto:204 rtt:32.1/4.0 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:128394 segs_out:402 segs_in:377 send 3.6Mbps lastsnd:12 lastrcv:10 lastack:10 pacing_rate 7.2Mbps retrans:4/210

Significado: Existen retransmisiones. Si retrans aumenta durante incidentes, tu “lentitud del modelo” podría ser pérdida de paquetes.

Decisión: Investiga congestión de red, mismatch de MTU, tablas de estado de firewall o agotamiento de NAT.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: “Está arriba, pero los usuarios dicen que las respuestas empeoraron”

Causa raíz: Deriva en la distribución de entradas, cambios en el corpus de recuperación o cambio de comportamiento del modelo upstream; falta monitorización de corrección.

Solución: Construye un conjunto de evaluación fijo; rastrea la calidad de las respuestas con etiquetas humanas o métricas proxy; añade detección de deriva en temas de consulta y en la distribución de documentos recuperados; añade un fallback seguro (solo recuperación).

2) Síntoma: p50 está bien, p99 es horrible

Causa raíz: Colas bajo carga, límites de tasa, saturación de GPU o I/O de recuperación lento.

Solución: Limita concurrencia; añade backpressure; prioriza peticiones; precomputa embeddings; mueve recuperación a memoria; aplica timeouts y abandona trabajo tardío.

3) Síntoma: Los costes suben pero el tráfico no lo hizo

Causa raíz: Tormentas de reintentos, prompts hinchados, misses de caché o respuestas verbosas.

Solución: Presupuestos de reintento; presupuestos de tamaño de prompt; límites de tokens de salida; normaliza claves de caché; cachea resultados intermedios de recuperación.

4) Síntoma: 429s aleatorios y timeouts, especialmente en horas punta

Causa raíz: Rate limiting del proveedor o saturación de tus propios pools de conexión.

Solución: Rate limiting cliente tipo token bucket; respeta Retry-After; implementa colas; estrategia multi-proveedor con comportamientos consistentes.

5) Síntoma: “Seguridad dice que no” y te quedas atascado meses

Causa raíz: Falta de clasificación de datos, retención poco clara y prompts que contienen contenido sensible.

Solución: Redacción antes de enviar; listas blancas para recuperación; cifrado; políticas de retención claras; limpieza de logs; realiza un threat model que incluya prompt injection y exfiltración de datos.

6) Síntoma: Gran demo, adopción terrible

Causa raíz: La función no se integra en el flujo de trabajo; latencia demasiado alta; resultados no confiables; no hay deshacer.

Solución: Modo consultivo; citas en línea; UX rápida de “aceptar/editar”; muestra confianza y fuentes; mantiene el flujo existente intacto.

7) Síntoma: El sistema “se cuelga” bajo carga y luego se recupera

Causa raíz: Head-of-line blocking, reintentos sincronizados o pausas de GC por prompts/logging enormes.

Solución: Colas separadas por prioridad; backoff con jitter; respuestas por streaming cuando sea posible; limita tamaños de payload; reduce logging sincrónico.

8) Síntoma: Escaladas legales/compliance tras el despliegue

Causa raíz: Generación sin límites sin checks de política; salidas que crean compromisos o asesoramiento regulado.

Solución: Filtros de salida; plantillas restringidas; disclaimers explícitos cuando se necesite; enruta intenciones de alto riesgo a humanos; registros de auditoría con citas.

Listas de verificación / plan paso a paso

Paso a paso: lanza una “función IA” sin convertir on-call en arte performático

1. Escribe una declaración de problema no-IA. Si no puedes, para. Estás a punto de construir teatro.
2. Elige la clase de función: determinista, probabilística o consultiva. Por defecto, consultiva.
3. Define SLOs: disponibilidad, latencia (p95/p99) y un proxy de corrección. Ponlos por escrito.
4. Define presupuestos: coste máximo por petición, techo mensual y un umbral de “apagado”.
5. Diseña fallbacks: respuesta en caché, solo recuperación, basada en reglas o “feature off”. Asegúrate de que los flujos centrales sigan funcionando.
6. Añade guardarraíles: validación de entradas, tamaño máximo de prompt, max tokens, timeouts, circuit breakers y rate limits.
7. Instrumenta por etapa: construcción de prompt, recuperación, inferencia, post-procesado, writeback. Necesitas un desglose de latencia.
8. Construye un arnés de evaluación: consultas de prueba fijas, citas esperadas, prompts de red team, umbrales de regresión.
9. Haz un rollout por fases: usuarios internos → cohorte pequeña → cohorts mayores. Vigila p99 y corrección.
10. Haz un game day: simula 429s upstream, ralentizaciones, salidas malas y deriva. Practica alternar fallbacks.
11. Operacionaliza el control de cambios: versiona prompts, fija modelos cuando sea posible, rastrea versiones del corpus y documenta notas de lanzamiento.
12. Establece responsabilidad: quién aprueba cambios de prompt/modelo, quién posee el runbook on-call, quién gestiona alarmas de presupuesto.

Lista: qué prohibir en producción por defecto

• Reintentos sin límite hacia un proveedor LLM upstream.
• Timeouts “a lo mejor” (cualquier cosa por encima de la ventana de paciencia del usuario).
• Desplegar sin rollback o modo fallback.
• Loggear prompts/respuestas crudas que contengan datos de clientes.
• Permitir que texto generado active acciones irreversibles (reembolsos, borrados, cambios de cuenta) sin una puerta determinista.
• “Un modelo para gobernarlos a todos” sin evaluación por casos de uso.

Lista: señales por las que debes alertar

• Latencia p99 por etapa de pipeline (recuperación vs inferencia vs post-procesado).
• 429 y 5xx desde proveedores upstream.
• Tasa de expulsión de caché y ratio de hits.
• Uso de tokens por petición (in/out), más su varianza.
• Profundidad de colas y tiempo en cola.
• Proxies de corrección: tasa de citas, fallos de validación, “pulgares abajo” de usuario, tasa de escalado.
• Indicadores de deriva: distribución de temas de consulta, cambios en distancias de embedding, cambios en la distribución de documentos recuperados.

Preguntas frecuentes

1) ¿Es “IA en todo” siempre malo?

No. Es malo cuando la etiqueta sustituye los requisitos. Pon IA donde la ayuda probabilística sea aceptable: redacción, resúmenes, búsqueda, sugerencias de enrutamiento. Sé conservador con acciones automáticas.

2) ¿Cuál es la mayor diferencia entre software clásico y funciones IA operativamente?

La corrección se vuelve estadística y variable en el tiempo. Tu sistema puede estar sano y equivocado. Necesitas arneses de evaluación y monitorización de deriva, no solo chequeos de uptime.

3) ¿Debemos alojar modelos nosotros o usar un proveedor?

Elige el modo de fallo que puedas operar. Los proveedores reducen la carga infra pero añaden límites de tasa, cambios opacos y riesgo de dependencia. Alojar da control pero añade scheduling de GPU, planificación de capacidad y superficie de seguridad. Híbrido es común: aloja para cargas previsibles, proveedor para picos.

4) ¿Qué medimos primero si no tenemos nada hoy?

Desglose de latencia por etapa, mezcla de errores upstream (429/5xx/timeouts), uso de tokens por petición, ratio de hits de caché y un solo proxy de corrección (feedback de usuarios o tasa de validación).

5) ¿Cómo evitamos que “cambios de prompt” sean cambios de producción sin revisión?

Versiona prompts como código. Requiere revisión. Ejecuta una suite de evaluación en CI. Loggea la versión del prompt por petición. Trata las ediciones de prompt como releases.

6) ¿Cuál es el fallback más simple y seguro para una función LLM?

Solo recuperación: devuelve los documentos/snippets superiores con enlaces/títulos (internamente) y deja que los usuarios lean. Es menos mágico y mucho más fiable.

7) ¿Cómo manejamos las alucinaciones sin fingir que no existen?

Constrén las salidas (formatos estructurados), exige citas, valida afirmaciones contra campos conocidos y enruta casos de alto impacto a humanos. También: mide la tasa de alucinaciones vía auditorías.

8) ¿Cachear respuestas LLM ayuda realmente?

Sí, si normalizas entradas y aceptas que algunas salidas se pueden reutilizar. Cachea resultados de recuperación, embeddings y post-procesado determinista también. No caches respuestas sensibles sin una política clara.

9) ¿Cuál es la trampa de coste más común?

Reintentos más salidas verbosas. Pagas la misma petición varias veces y luego pagas por exceso de tokens. Presupuesta reintentos y limita longitud de generación.

10) ¿Cómo explicamos la fiabilidad de IA a ejecutivos que quieren la etiqueta?

Traduce a riesgo: latencia cola, dependencia de proveedores, regresiones de corrección y exposición de cumplimiento. Luego ofrece un rollout por fases con resultados medibles e interruptores de apagado.

Conclusión: próximos pasos que puedes tomar esta semana

“IA en todo” no es una estrategia. Es una etiqueta. Tu trabajo es convertir etiquetas en sistemas que se comporten bajo presión.

1. Elige una función IA y escribe su métrica de resultado, métrica de daño, presupuesto de latencia y presupuesto de coste en una página.
2. Añade un modo fallback que preserve el flujo cuando el modelo sea lento, esté equivocado o tenga rate limit.
3. Instrumenta la latencia por etapa para poder responder “¿dónde se fue el tiempo?” sin adivinar.
4. Construye un pequeño arnés de evaluación (20–50 consultas representativas) y ejecútalo antes de cada cambio de prompt/modelo/corpus.
5. Configura alertas sobre 429s, reintentos, uso de tokens, expulsiones de caché y p99 por etapa. No porque las alertas sean divertidas—porque las sorpresas son caras.

Si haces esas cinco cosas, la etiqueta puede seguir siendo ridícula mientras la función se vuelve real. Ese es el único intercambio que funciona en producción.