Knowledge cutoff (fecha de corte): hasta cuándo sabe la IA

¿Qué significa?

Un modelo se entrena con texto recopilado hasta cierto momento. Después se evalúa, se ajusta y se publica, y luego la gente lo usa durante meses o años. Por eso, cuando alguien le escribe, el mundo ya siguió avanzando sin él.

Un caso concreto: según la tabla de modelos de Anthropic, consultada el 31 de octubre de 2026, Claude Sonnet 5.5 tiene un corte en junio de 2026, y la empresa se compromete a no retirarlo antes del 28 de septiembre de 2027. Es decir, puede seguir en uso más de un año después de la fecha hasta la que llegan sus datos. Hoy mismo, con un corte en junio, ya lleva unos cuatro meses de retraso respecto a la fecha de hoy.

Esto no significa que el modelo “se apague” en esa fecha. Significa que no tiene información confiable sobre lo que pasó después, salvo que la reciba en la conversación o por una herramienta.

¿Qué fechas declaran hoy los proveedores?

Estas son las fechas que figuran en la documentación oficial, consultada el 31 de octubre de 2026. Cambian con cada modelo nuevo, así que verifica la página del proveedor antes de citarlas.

Dos detalles útiles. Primero, Anthropic distingue en su tabla el corte de conocimiento fiable (hasta cuándo el conocimiento del modelo es más extenso y fiable) del corte de datos de entrenamiento (el rango más amplio de datos usados). Para los modelos 5.5 ambos coinciden, pero en general no tienen por qué. Segundo, un proveedor puede no publicar la fecha: si no está en la documentación, no la deduzcas de un sitio de terceros. Esos sitios a veces dan cifras que el proveedor nunca confirmó.

¿Por qué le importa a un diseñador?

Porque el modelo puede hablar con seguridad de cosas que ya cambiaron:

• Versiones y precios. Una interfaz que sugiere “la última versión de la librería” o “el precio actual” puede mostrar un dato viejo como si fuera vigente.
• Normas y tendencias. Un asistente que recomienda prácticas de accesibilidad o cita leyes de protección de datos debe dejar claro hasta qué fecha llega lo que sabe.
• Confianza. Un error de fecha lo ve cualquier usuario que conoce el tema, y eso afecta la credibilidad de todo el producto, no solo de una respuesta. Es una forma de alucinación difícil de detectar, porque el dato fue cierto alguna vez.
• Expectativa. El usuario supone que la IA “lo sabe todo”. Explicar el límite temporal en el onboarding corrige esa suposición.

La fecha de corte casi no importa cuando la tarea no depende de hechos recientes: explicar un concepto de diseño, reescribir un texto, traducir o estructurar una lista.

¿La fecha publicada es exacta?

No del todo. El artículo “Dated Data: Tracing Knowledge Cutoffs in Large Language Models” (Cheng y colaboradores, 2024) define un corte efectivo, que puede diferir de la fecha que reporta el desarrollador y variar según la fuente de datos o el tema. Los autores identifican dos causas de esa diferencia: los volcados nuevos de CommonCrawl contienen una cantidad no trivial de datos viejos, y los esquemas de deduplicación se complican con duplicados semánticos y casi-duplicados léxicos. Su conclusión es que una sola fecha no cuenta toda la historia.

Para tu producto, la fecha de corte es una referencia aproximada, no una garantía. Si una pregunta depende de hechos recientes, asume que el modelo puede estar más atrasado de lo que dice la tabla y verifica con una fuente actual.

¿Cómo compensarlo?

Hay tres formas, de la más simple a la más completa:

1. Pasar la fecha actual en el prompt del sistema, para que el modelo sepa en qué momento está. Es una línea de texto y evita que calcule edades, plazos o “el año pasado” con el calendario equivocado.
2. Darle información reciente. Con una herramienta de búsqueda web o con RAG sobre fuentes actualizadas. La documentación de Anthropic describe su herramienta de búsqueda web como un acceso a contenido en tiempo real para responder con información posterior al corte, con citas de las fuentes; la guía de búsqueda web de OpenAI describe lo mismo. Si lo que necesitas cabe en el texto, basta con incluirlo en la petición, siempre que quepa en la ventana de contexto.
3. Diseñar la respuesta para que muestre la fecha de los datos cuando importe: “Fuente: documentación consultada el 31 de octubre de 2026”.

El fine-tuning no es una buena vía para novedades: habría que repetirlo cada vez que el dato cambie, mientras que pasar el dato en la petición o recuperarlo con búsqueda se actualiza al instante.

Ejemplo

Ejemplo ilustrativo: un asistente de diseño recomienda una librería de componentes para un proyecto nuevo. La respuesta menciona una versión que ya no se mantiene. El equipo agrega tres cambios: pasa la fecha actual en el prompt del sistema; cuando la pregunta trata de versiones, busca en la documentación oficial antes de responder; y la interfaz muestra “Fuente: documentación consultada el 31 de octubre de 2026” junto a la recomendación. Si la búsqueda no devuelve nada, el asistente responde “no encuentro la versión vigente; esto es lo que sabía hasta mi fecha de corte” en lugar de adivinar.

Errores comunes

• Creer que el modelo conoce la fecha actual sin que se le diga.
• Confiar en una fecha de corte publicada como si fuera exacta.
• Copiar de un sitio de terceros una fecha de corte que el proveedor no publica.
• Mezclar datos de distintas fechas en la misma respuesta sin avisarlo.
• Usar fine-tuning para agregar noticias o versiones nuevas.
• Mostrar datos antiguos con el mismo tono que los vigentes, sin indicar su fecha.

Fuentes

• Models overview (Anthropic, documentación de la plataforma Claude), consultada el 31 de octubre de 2026
• GPT-6 Astra (OpenAI, documentación de modelos), consultada el 31 de octubre de 2026
• Models (OpenAI, lista de modelos), consultada el 31 de octubre de 2026
• Gemini models (Google AI for Developers), consultada el 31 de octubre de 2026
• Dated Data: Tracing Knowledge Cutoffs in Large Language Models (arXiv:2403.12958)
• Web search tool (Anthropic, documentación de la plataforma Claude)
• Web search (OpenAI, guía de la API)