Un proveedor presenta un modelo compacto que funciona en equipos controlados por tu empresa. Sigue instrucciones, utiliza herramientas informáticas y completa una tarea preparada sin enviar los datos a un gran servicio en la nube. La conclusión parece evidente: ya existe un agente de IA privado listo para trabajar en el negocio.

Una demostración cubre la parte fácil. La decisión de compra depende de lo que ocurre cuando el avance se bloquea, falta información o el modelo debería entregar la tarea a una persona.

Hemos probado dos modelos pequeños recientes, K2 Horizon 7B y Ornith 1.5 9B, dentro de sistemas de agentes locales. Ambos mostraron capacidades útiles. También dejaron al descubierto la distancia entre saber ejecutar acciones y ser lo bastante fiables para asumir un proceso empresarial. K2 rindió mejor en general durante nuestras pruebas, pero ninguno estaba preparado para trabajar sin límites firmes y supervisión.

Respuesta breve

Los modelos locales pequeños ya pueden entender un objetivo, elegir herramientas y completar trabajos cortos y predecibles. Su punto débil aparece cuando falla la ruta prevista. En nuestras pruebas repitieron acciones sin avanzar, continuaron después de recibir una orden de parada y, en un caso, añadieron datos sin respaldo después de reconocer correctamente que no disponían de la información necesaria.

Los agentes de IA local pueden resultar útiles siempre que el modelo no sea el único mecanismo de control. La empresa también necesita un programa que limite los intentos, compruebe los datos importantes, registre lo ocurrido y envíe los casos dudosos a un empleado. Un proveedor que venda «IA con agentes» debe enseñar esos controles, además de una demostración que sale bien.

Por qué probamos K2 y Ornith

K2 Horizon 7B y Ornith 1.5 9B pertenecen a una nueva categoría de modelos suficientemente pequeños para funcionar en local, pero promocionados para razonar, utilizar herramientas informáticas y realizar trabajos con varios pasos. La combinación resulta atractiva para empresas que quieren controlar mejor sus datos y sus costes sin renunciar a la automatización.

Los dos forman parte de una dirección más amplia del mercado. Qwen3.5-9B, LFM2.5-8B-A1B, Ling 3.0 tiny y Granite 4.2 8B también se han publicado o presentado para razonamiento local y trabajo como agentes durante 2026. Estos nombres aportan contexto de mercado, no recomendaciones: la promesa de agentes locales capaces está entrando con rapidez en el discurso comercial habitual.

Nuestro objetivo era práctico. Comprobamos si los modelos podían seguir un objetivo, utilizar las herramientas disponibles, reconocer que habían dejado de avanzar, respetar una regla clara de parada y evitar datos sin verificar en la respuesta final.

Lo que los modelos ya saben hacer

Ambos modelos entendieron las instrucciones y utilizaron correctamente las herramientas cuando el trabajo era corto y las condiciones resultaban predecibles. Mantuvieron el objetivo general y propusieron pasos razonables. Son capacidades reales y explican por qué una demostración bien preparada puede resultar convincente.

K2 fue el más disciplinado de los dos en las ejecuciones observadas. En general llegó antes a acciones útiles y consumió menos recursos. Ornith tardó más y generó más actividad sin entregar un resultado limpio cuando el trabajo se complicó. Las diferencias entre tareas y condiciones impiden establecer una clasificación general. La comparación sí muestra que elegir el modelo más capaz no elimina la necesidad de gestionar los fallos.

Dónde se perdió la fiabilidad

Cuando la ruta normal dejó de funcionar, los modelos mantuvieron presente el objetivo y continuaron generando acciones que parecían razonables por separado. El conjunto de la secuencia, sin embargo, ya no avanzaba hacia un resultado verificable.

Este comportamiento puede pasar desapercibido durante una demostración comercial. El agente mantiene la actividad y explica lo que hace, así que parece estar resolviendo el problema. La empresa puede acabar con una tarea retrasada, un mayor gasto informático y un empleado que todavía debe averiguar si se ha conseguido algo útil.

Una empresa debe medir el avance verificable en lugar de la actividad visible. Un agente debe entregar un resultado respaldado por pruebas o detenerse con una explicación clara que permita continuar a otra persona.

Flujo visual que compara acciones repetidas de un agente de IA con un camino corto hacia un resultado verificado

Uno de los fallos afectaba a la capacidad de detenerse. En una ejecución con K2, indicamos al agente que informara del obstáculo y terminara la tarea después del segundo intento fallido. Continuó probando.

Muchas propuestas de IA presentan las reglas escritas en el prompt como controles de seguridad. Pueden influir en el comportamiento, pero el modelo vuelve a interpretarlas cada vez que elige la siguiente acción. Una petición de parada es más débil que un límite fijo en el programa que rodea al modelo.

La diferencia tiene consecuencias prácticas. Si un proveedor promete un número máximo de intentos, el sistema debe terminar la ejecución al alcanzar ese límite. Si una acción necesita aprobación, el programa debe bloquear el permiso hasta que lo conceda una persona autorizada. Los límites importantes tienen que funcionar incluso cuando el modelo toma una mala decisión.

Otra ejecución con K2 reveló un problema más serio. La información necesaria para terminar el trabajo no estaba disponible. El agente reconoció el obstáculo y lo explicó con claridad, pero después añadió detalles que no había comprobado. Algunos eran incorrectos.

La respuesta sonaba responsable porque reconocía abiertamente la limitación. Ese tono hacía más fácil confiar en los datos sin respaldo. Una persona que revise un informe largo puede asumir de forma razonable que todo lo escrito después del aviso también ha sido comprobado.

Para trabajar en una empresa, reconocer la incertidumbre es solo el primer paso. El sistema debe mantener ese límite durante toda la respuesta. Cuando faltan pruebas, los campos correspondientes deben quedar vacíos o marcados para revisión. Un aviso redactado con prudencia no protege a la empresa frente a un error convincente en otra parte del mismo resultado.

Lo que un benchmark no resuelve

La presentación oficial de K2 recoge resultados sólidos en benchmarks de programación, razonamiento y agentes. IFM también publica más material de apoyo que muchos fabricantes, incluidos los pesos, el código, información sobre el entrenamiento y evaluaciones detalladas. El progreso descrito es creíble, y nuestras ejecuciones controladas confirmaron que un modelo pequeño puede completar correctamente un trabajo acotado.

La misma publicación reconoce que la exploración extensa y la recuperación repetida después de errores siguen siendo difíciles para los modelos más pequeños. Esta limitación importa porque los procesos empresariales rara vez permanecen dentro de una demostración preparada.

Un benchmark es una prueba normalizada bajo condiciones definidas. Puede confirmar que un modelo posee una capacidad, pero el comprador aún necesita comprobar que el sistema completo se comporta correctamente cuando cambian las condiciones.

Una afirmación comercial puede decir La empresa todavía debe comprobar
Buen rendimiento en tareas de agentes Si el sistema reconoce un punto muerto y se detiene
Puede completar trabajos con varios pasos Si las acciones posteriores siguen contribuyendo al resultado
Sabe utilizar herramientas informáticas Si comprueba la información que devuelven esas herramientas
Sigue instrucciones Si los límites importantes se imponen fuera del modelo
Puede explicar un fallo Si la respuesta final permanece libre de datos inventados

La puntuación puede ser correcta y, aun así, la conclusión comercial puede resultar demasiado amplia. Un modelo puede rendir bien en la prueba publicada y necesitar bastante supervisión dentro de un proceso empresarial.

Qué significa para una empresa

K2 y Ornith son componentes capaces. Ninguno debe tratarse como un empleado autónomo terminado. Los modelos locales pequeños encajan mejor cuando el trabajo tiene límites claros, el acceso está restringido, los datos importantes pueden comprobarse de forma automática y una persona se ocupa de las excepciones.

El riesgo aumenta cuando el agente recibe permisos amplios, un objetivo abierto y ninguna definición fiable del éxito o el fracaso. En esas condiciones, un modelo que se expresa con soltura puede seguir trabajando mucho después de dejar de avanzar. También puede convertir la falta de información en una respuesta que parece completa.

El proveedor debe responder por algo más que la selección del modelo. La propuesta tiene que explicar cómo detiene los intentos repetidos, protege los datos importantes, registra la fuente de las respuestas, solicita aprobaciones y devuelve el trabajo pendiente a un empleado. Estos controles forman parte del producto y de su coste.

Modelo de IA local rodeado de un límite de parada, comprobación de fuentes, control de acceso y aprobación humana

Antes de aprobar un agente de IA local, conviene preguntar al proveedor:

  1. ¿Qué ocurre cuando el modelo no puede completar la tarea?
  2. ¿Qué límites impone el programa y cuáles aparecen únicamente en el prompt?
  3. ¿Puede un empleado localizar la fuente de cada dato importante?
  4. ¿Qué acciones requieren siempre la aprobación de una persona?
  5. ¿Quién mantiene los controles cuando cambia el modelo o el programa conectado?

Las respuestas aportan más información que otra demostración perfecta. Permiten saber si el proveedor ha construido un sistema empresarial fiable o se ha limitado a conectar un modelo capaz con varias herramientas.

Nuestra guía general explica si una pyme necesita realmente un agente de IA. Si la propuesta incluye ejecutar el modelo en equipos propios, revisa los costes y las condiciones de los LLM locales. Nuestro trabajo de IA y automatización de procesos empieza por el proceso, sus riesgos y las personas responsables antes de conceder acceso a cualquier modelo.

Nuestra conclusión después de probar ambos modelos

K2 y Ornith demostraron que los modelos locales pequeños ya pueden realizar trabajo útil con herramientas informáticas. También dejaron claro que saber actuar y trabajar con autonomía corresponden a niveles distintos de capacidad. K2 fue más sólido en nuestras pruebas, pero aun así continuó después de una regla de parada y produjo información sin respaldo cuando faltaban pruebas.

Las empresas pueden utilizar modelos locales pequeños si mantienen expectativas precisas. Conviene tratar el modelo como una parte de un proceso controlado, probar cómo falla antes de ampliar sus accesos y asignar a una persona la responsabilidad sobre las excepciones. Nosotros hicimos esas pruebas porque la parte difícil de un agente de IA empieza donde termina la demostración preparada.

Fuentes y método

Las observaciones proceden de pruebas de implementación de Taronja Nova con una ejecución observada por condición. Probamos K2 en más condiciones que Ornith y las tareas fueron distintas. Por tanto, los resultados son cualitativos y no permiten calcular una tasa general de fallos para ninguno de los modelos.