Contexto técnico
Me encantan estas señales de campo más que cualquier benchmark brillante. Cuando alguien escribe que Kimi es más cómodo para pruebas, Sonnet 4.6 es más flexible, y que ante la palabra "ciberseguridad" algunos modelos simplemente se bloquean, pienso de inmediato no en tablas de clasificación, sino en la integración real de IA en el flujo de trabajo.
Y aquí el panorama es bastante realista. Kimi se desempeña bien en tareas estructuradas de seguridad: CTF, forense, análisis de artefactos, investigación paso a paso. Según mis observaciones, a menudo intenta ser más completo que preciso, lo cual puede ser una ventaja en un entorno de pruebas.
Sonnet 4.6 también me resulta comprensible. No siempre es el más audaz en profundidad, pero suele mantener una línea de razonamiento más estable y se desmorona menos en cadenas largas. Cuando no necesito magia puntual sino un comportamiento predecible en automatización con IA para procesos de equipo, esa estabilidad vale más que un único resultado "wow".
Con Codex la historia es diferente. Es interesante no porque "piense mejor en seguridad", sino porque lleva las tareas a código funcional, integraciones y resultados útiles más rápido. Si el acceso a confirmación extendida y complementos está abierto, encaja bien en escenarios de ingeniería donde el objetivo no es discutir con el modelo, sino construir una herramienta.
Y los bloqueos en Anthropic y los estrictos filtros de seguridad en modelos de frontera ya son parte de la arquitectura, no un accidente. Por lo tanto, elegir un modelo para ciberseguridad debe considerar no solo la calidad de las respuestas, sino si sobrevivirá al mero contexto de seguridad sin negarse.
Qué cambia para el negocio y la automatización
En resumen, ganan quienes separan los roles de los modelos. Yo consideraría Kimi para pruebas de investigación y laboratorios, Sonnet 4.6 para procesos de producción más estables, y Codex para construir utilidades, agentes internos e integraciones de seguridad rápidas.
Pierden los equipos que intentan cargar todo el perímetro en un solo modelo. En la práctica, te encontrarás con bloqueos de seguridad, ejecución débil o el costo de errores en escenarios largos.
Veo constantemente estas bifurcaciones en proyectos. En Nahornyi AI Lab no discutimos qué modelo es "mejor", sino que ensamblamos una arquitectura de soluciones de IA para el riesgo, accesos y tipo de tarea concretos, para que la automatización con IA no se rompa ante el primer prompt sensible.
Si tu equipo de seguridad pasa horas en análisis manual, triage o herramientas internas, puedes descomponerlo tranquilamente en bloques manejables. Y luego, con esos bloques en Nahornyi AI Lab junto a Vadym Nahornyi, construir un desarrollo de soluciones de IA sin cuentos sobre un modelo universal, pero con resultados reales en producción.