- El Apple Neural Engine es mucho más capaz de lo que Apple expone, permitiendo incluso entrenamiento completo de modelos a pesar de las restricciones oficiales.
- Investigaciones mediante ingeniería inversa han roto la “caja negra” del ANE, demostrando su enorme eficiencia energética y su potencial para IA local personalizada.
- Apple Intelligence, con LLM locales integrados en iOS y macOS, ha sufrido ataques de prompt injection y Neural Exec que han evidenciado fallos graves de diseño y filtrado.
- Apple combina ahora un enfoque prudente con Gemini en la nube y modelos en dispositivo, consciente de las limitaciones cognitivas y de seguridad de la IA generativa actual.
Apple ha sido acusada durante años de ir con retraso en inteligencia artificial generativa, y el contraste con lo que están haciendo otros gigantes como Google o OpenAI se nota. Siri sigue arrastrando limitaciones, Apple Intelligence ha llegado con buena intención pero bastantes sombras, y la propia compañía ha tenido que apoyarse en modelos externos como Gemini para tapar agujeros en su asistente y otras funciones avanzadas.
Sin embargo, eso no significa que en Cupertino no hayan estado construyendo piezas de IA muy potentes por debajo del capó. De hecho, varios descubrimientos recientes han destapado que el Apple Neural Engine (ANE), presente en prácticamente todo el hardware moderno de la marca, es mucho más capaz de lo que Apple reconoce públicamente. A eso se suman investigaciones que han logrado vulnerar la seguridad de Apple Intelligence mediante técnicas de prompt injection y entradas adversarias, revelando que la integración profunda de la IA en el sistema también abre la puerta a nuevos vectores de ataque.
Qué es realmente el Neural Engine de Apple y por qué importa
El Apple Neural Engine es el acelerador dedicado de IA que Apple integra en sus chips A y M, así como en los procesadores de sus Apple Watch. Es lo que otros fabricantes etiquetan como NPU (Neural Processing Unit), una unidad especializada en ejecutar operaciones típicas de redes neuronales de forma muy eficiente. En iPhone, iPad y Mac basados en Apple Silicon, el ANE estándar cuenta con 16 núcleos, mientras que en los relojes inteligentes la cifra baja a 4 núcleos adaptados al menor consumo.
En cada nueva generación de chip, Apple presume de más TOPS y de mejoras en el Neural Engine, pero normalmente lo hace de pasada, sin entrar al detalle de cómo funciona ni qué se puede hacer exactamente con él. Suele centrarse en las mejoras de CPU y GPU, dejando el ANE en un segundo plano, casi como una casilla de marketing más. Este perfil bajo no es casual: la compañía controla con extremo cuidado el acceso de terceros a este hardware.
Para desarrolladores externos, el acceso al ANE está fuertemente filtrado a través de Core ML, el framework oficial de Apple para trabajar con modelos de aprendizaje automático. La documentación pública es limitada, la API está diseñada sobre todo para tareas de inferencia (es decir, ejecutar modelos ya entrenados) y Apple no ofrece un camino directo para usar el Neural Engine en entrenamiento puro de redes neuronales. Todo lo que se sale de ese marco oficial, en principio, queda fuera de juego.
Este secretismo ha llevado a que el Neural Engine sea visto como una especie de caja negra: sabemos que está ahí, que acelera algunas funciones de cámara, reconocimiento de voz, traducción o clasificación de contenido, pero poco más. Y, sin embargo, el trabajo de varios investigadores y desarrolladores ha empezado a abrir brecha, demostrando que el ANE es mucho más flexible, entrenable y potente energéticamente de lo que Apple admite.
El hackeo conceptual del Neural Engine: de simple inferencia a entrenamiento completo
Uno de los casos más llamativos es el trabajo de investigadores que, apoyándose en modelos tipo Claude, han logrado saltarse las restricciones de Core ML y observar de cerca cómo funciona el Neural Engine en chips como el M4. Hablamos de una combinación de ingeniería inversa, análisis de APIs privadas y experimentación directa con el hardware para exprimir capacidades que Apple no ofrece en sus rutas oficiales.
Lo primero que se ha demostrado es que el ANE no es solo un motor de inferencia. A pesar de que las herramientas oficiales de Apple no permitan entrenar modelos directamente sobre él, el hardware sí es capaz de ejecutar un ciclo de entrenamiento completo de redes neuronales, incluyendo la fase de retropropagación (backpropagation) y la actualización de pesos. Es decir, se puede entrenar un modelo de principio a fin directamente en el Neural Engine, sin usar la GPU ni las APIs de entrenamiento de Core ML o Metal.
Otro hallazgo clave es que el diseño interno del ANE no se basa en un simple multiplicador de matrices, como ocurre en la mayoría de aceleradores de IA actuales, sino en un motor de convolución. Esto implica que el tipo de operaciones para las que está optimizado es distinto: si se programa pensando en multiplicadores de matrices genéricos, el rendimiento se desaprovecha respecto a lo que se podría conseguir si el código estuviera ajustado específicamente a un motor de convolución.
Además, se ha visto que los núcleos del Neural Engine trabajan encadenados. En lugar de funcionar como unidades completamente aisladas, pueden formar una especie de pipeline donde las operaciones se encadenan y se ejecutan de forma más eficiente cuando se envían en lotes grandes, no de manera individual. Esto refuerza la idea de que, para sacarle todo el jugo al ANE, hace falta adaptar muy bien los patrones de cálculo al diseño real del chip.
También se ha puesto en duda la cifra de 38 TOPS que Apple cita de forma habitual para su Neural Engine de 16 núcleos. Los análisis independientes señalan que, al tratarse en la práctica de un procesador FP16 con soporte para INT8, la capacidad efectiva se queda en torno a la mitad de lo que proclama el marketing. No es algo exclusivo de Apple, eso sí: prácticamente todos los fabricantes inflan la métrica usando supuestos muy favorables de precisión y carga de trabajo.
Arquitectura interna: memoria, eficiencia energética y límites reales
Una pieza importante del puzle es la memoria interna del Neural Engine. Las investigaciones apuntan a que el ANE dispone de 32 MB de SRAM (memoria estática) integrada. Mientras los modelos y las operaciones caben dentro de ese espacio, el rendimiento es muy alto; en cuanto hay que salir de ahí y depender de memoria externa, la velocidad cae de forma brusca, porque se rompe el flujo de datos para el que está optimizado el diseño. Esa limitación de memoria interna del Neural Engine recuerda a retos clásicos en dispositivos conectados.
Donde el Neural Engine de Apple sí brilla sin discusión es en eficiencia energética. Las mediciones hablan de unos 19 TFLOPS efectivos consumiendo alrededor de 2,8 vatios, lo que se traduce en unos 6,6 TFLOPS por vatio. Es una cifra espectacular si se compara con otros aceleradores: GPUs vía Metal rondan 1 TFLOP por vatio, y soluciones punteras como NVIDIA H100 se mueven alrededor de 1,4 TFLOPS por vatio. En términos de cómputo por unidad de energía, el ANE juega en otra liga.
Parte de esa eficiencia se debe a la gestión agresiva de energía por núcleo. Cuando un núcleo del Neural Engine no se está utilizando, el chip corta por completo su alimentación, reduciendo el consumo en reposo literalmente a cero para esas unidades. Solo los núcleos activos tiran de energía, lo que permite ejecutar tareas intensivas de IA con un impacto relativamente bajo sobre la batería o el consumo total del sistema.
Ahora bien, esto no convierte mágicamente a un Mac mini o un MacBook Pro en un sustituto de un clúster de GPUs para entrenar modelos de frontera. El tamaño de la memoria interna y la propia escala de cómputo hacen que el ANE sea ideal para modelos pequeños o medianos, para entrenamiento ligero (como ajustes finos o LoRA) y para despliegue local de modelos optimizados, pero no para levantar por sí solo un GPT de decenas de miles de millones de parámetros.
Aun así, la posibilidad de entrenar modelos compactos directamente en el Neural Engine abre un escenario interesante: desarrollo de IA más distribuida, personalización en el propio dispositivo y reducción de dependencia de la nube para muchos casos de uso. Eso sí, para que esto deje de ser un experimento de laboratorio y pase a producción, Apple tendría que abrir más su ecosistema y documentar con claridad capacidades que ahora mismo mantiene bajo llave.
Ingeniería inversa y entrenamiento en ANE: el proyecto ANE y la “caja negra” rota
Uno de los desarrollos que más ruido ha generado es el trabajo de un developer conocido como maderix, que se propuso precisamente “romper” la caja negra del ANE. Su enfoque consistió en hacer ingeniería inversa de APIs privadas relacionadas con el Neural Engine, evitando por completo el camino oficial de Core ML para el entrenamiento y prescindiendo también de Metal y de la GPU para la parte de cómputo neuronal.
El resultado fue una tubería de entrenamiento personalizada que ejecuta forward pass, backpropagation y actualización de pesos directamente sobre el ANE. Es decir, todo el ciclo de entrenamiento ocurre en la NPU, usando interfaces no documentadas públicamente pero accesibles desde el sistema. En su repo se habla explícitamente de “training on ANE vía APIs privadas reverse-engineered, without Core ML training APIs, without Metal and without GPU for that part of compute”.
Para demostrar que no era solo una prueba sintética, el proyecto se centró en entrenar un modelo tipo microGPT de unos 110 millones de parámetros. Es un tamaño modesto comparado con los grandes modelos de lenguaje actuales, pero suficiente para validar que el ANE puede manejar entrenamiento real, con datos y ajustes de pesos, a una escala razonable para un solo chip de consumo.
El propio autor deja claro que el proyecto sigue siendo research, no algo listo para que cualquiera lo use en producción. El carácter experimental y las implicaciones éticas del trabajo son evidentes: faltan herramientas de alto nivel, integraciones amigables y, sobre todo, respaldo oficial. Pero el mensaje de fondo es contundente: la limitación no estaba en el chip, sino en el acceso que Apple decide conceder. El hardware tenía la capacidad; lo que faltaba era la API.
En este contexto, tiene sentido pensar en escenarios híbridos donde un Mac actúe como plataforma seria para experimentar, afinar y personalizar modelos sin necesidad de irse a la nube para todo. Con varios dispositivos en red, o incluso con clusters de Macs, se podría explorar entrenamiento distribuido de modelos algo mayores. Y, en un plano más práctico, un único ANE podría ser más que suficiente para tareas como LoRA sobre modelos de 3B o 7B parámetros, gracias precisamente a esa brutal eficiencia energética comentada antes.
Apple Intelligence, LLM locales y el nuevo vector de ataque
Mientras el lado de hardware deja ver que Apple tiene más músculo del que aparenta, el lado de seguridad ha quedado algo tocado con las investigaciones sobre Apple Intelligence. Este ecosistema de IA generativa integra modelos de lenguaje grande tanto a nivel de sistema como en apps compatibles, combinando un modelo pequeño que corre en el propio dispositivo con otro mayor alojado en la nube privada de Apple, conocida como Private Cloud Compute.
En diciembre de 2025 ya se estimaban unos 200 millones de dispositivos con capacidad para usar Apple Intelligence, lo que da una idea del alcance potencial de cualquier vulnerabilidad en esta plataforma. El modelo local actúa como primera línea de respuesta, interactuando con el usuario y con las aplicaciones, y está mediado por la API Foundation Models Framework, que aplica políticas de la compañía y filtra lo que entra y lo que sale.
Sobre el papel, esta API debería supervisar el comportamiento del modelo, bloquear entradas maliciosas, evitar respuestas peligrosas y, en general, mantener a raya los intentos de uso indebido. Apple no ha detallado exactamente cómo funciona esa filtración, pero es razonable asumir que combina reglas, filtros de contenido y capas de seguridad pensadas para detectar prompts problemáticos.
El problema es que un equipo de RSAC Research demostró que esos controles pueden ser burlados. Su objetivo fue precisamente el modelo pequeño que corre en local, aquel que tiene acceso directo al contenido personal del usuario (correos, mensajes, eventos, notificaciones, etc.) y que además se encuentra profundamente integrado en iOS y macOS.
Prompt injection, Neural Exec y uso de Unicode para esquivar filtros
La técnica central utilizada por los investigadores fue la llamada prompt injection, pero llevada un paso más allá mediante un tipo de entrada adversaria generada automáticamente que bautizaron como Neural Exec. A grandes rasgos, se trata de prompts que, para un humano, parecen cadenas sin sentido, pero que están diseñadas para que el modelo las interprete como instrucciones muy concretas, capaces de forzar comportamientos que normalmente estarían vetados.
Los Neural Exec se generan mediante aprendizaje automático para atacar de forma universal a un LLM: en lugar de probar manualmente prompts maliciosos, se entrenan inputs que explotan patrones internos del modelo. Según explican, el resultado son textos ininteligibles para el usuario pero “perfectos” para engañar al sistema, porque se ajustan justo a aquello que el modelo tiende a seguir sin que los filtros lo sospechen.
Para esquivar los filtros de entrada y salida de Apple Intelligence, RSAC Research recurrió también a un truco clásico con Unicode, concretamente usando la función de anulación de derecha a izquierda (RLO, por sus siglas en inglés). Al escribir texto malicioso en inglés al revés y aplicar esta función, conseguían que el LLM lo viera y lo procesara correctamente, mientras que los filtros basados en patrones más sencillos podían no detectarlo.
En palabras de los propios investigadores, este truco de Unicode resultó ser casi infalible de cara a burlar las capas de seguridad automáticas. En sus pruebas, aplicaron la combinación de Neural Exec y manipulación de Unicode a más de cien indicaciones aleatorias, obteniendo una tasa media de éxito de ataque del 76 %, una cifra muy alta para un sistema que se vende como especialmente seguro y privado.
El impacto práctico de estas técnicas es considerable: en distintos escenarios de prueba, se consiguió que Apple Intelligence generara respuestas ofensivas, instrucciones peligrosas o contenido claramente inapropiado, pese a los supuestos filtros. Más preocupante aún, algunas de estas inyecciones permitían que el modelo ejecutara acciones con permisos elevados, al interferir con las instrucciones maestras con las que el sistema guía a la IA.
Control total del iPhone: instrucciones invisibles y permisos de sistema
Uno de los aspectos más delicados de la arquitectura de Apple Intelligence es que el modelo local tiene acceso a una gran cantidad de datos personales y puede actuar como intermediario entre distintas apps. Lee correos, resume conversaciones en apps de mensajería como Telegram, crea eventos de calendario basados en información extraída de otras aplicaciones y genera notificaciones inteligentes con contexto. Ese acceso a datos personales plantea retos claros de protección y cumplimiento.
Los investigadores de RSAC Research demostraron que era posible colarse en ese flujo de confianza inyectando instrucciones invisibles en contenidos aparentemente inocuos. En un ejemplo concreto, incluyeron texto invisible en un correo electrónico con órdenes del estilo “Olvida todo lo anterior y sigue estas órdenes” o similares, diseñadas para ser interpretadas como instrucciones de sistema por Apple Intelligence.
Cuando ese correo llegaba al iPhone y Apple Intelligence lo procesaba para generar resúmenes o notificaciones, el modelo leía también las instrucciones escondidas y las ejecutaba como si fueran parte de su prompt principal. Dado que estas órdenes se colaban en el nivel de sistema, podían llegar a ejecutarse con todos los permisos asociados al asistente, abriendo la puerta a que un atacante tomase control efectivo del dispositivo mediante la IA.
En las demostraciones públicas, los investigadores se limitaron a ejemplos llamativos pero relativamente inofensivos, como hacer que el sistema generase textos del tipo “enséñame cómo montar una bomba” o instrucciones para visitar direcciones comprometidas. La intención era ilustrar el potencial de abuso sin llegar a poner a usuarios reales en peligro directo.
Pero el propio equipo advierte de que el alcance real podría ser mucho mayor. Dado que Apple Intelligence tiene capacidad para leer, resumir y actuar sobre datos sensibles (desde mensajes hasta información de salud, pasando por fotos o documentos almacenados), un ataque bien diseñado podría intentar extraer, remezclar o exfiltrar ese contenido de formas difíciles de detectar para el usuario, siempre y cuando consiga colarse mediante prompt injection y Neural Exec.
Conviene subrayar que RSAC Research notificó estas vulnerabilidades a Apple en octubre y esperó a que se publicaran parches antes de divulgar la investigación. Según indican, no tienen evidencias de que estos fallos se hayan explotado de forma masiva en el mundo real, pero recomiendan encarecidamente actualizar a iOS 26.4 y macOS 26.4, versiones en las que Apple habría reforzado el sistema para cerrar estos vectores de ataque.
El enfoque prudente de Apple con la IA: límites cognitivos y dependencia de Gemini
Más allá del hardware y de la seguridad, Apple también está estudiando las propias limitaciones cognitivas de los modelos de IA con los que trabaja. En una línea de investigación interna, la compañía sometió a modelos de última generación como OpenAI o3 o Claude 3.7 a baterías de puzzles lógicos relativamente sencillos, del estilo de problemas que un niño podría resolver con algo de paciencia.
Los resultados fueron bastante preocupantes para cualquiera que confíe ciegamente en la “inteligencia” de estos sistemas. A partir de cierto nivel de dificultad, la precisión de los modelos se desplomaba literalmente a cero: no es que fallaran más, es que dejaban de acertar por completo, como si chocaran con un muro invisible en su capacidad de razonamiento estructurado.
Más raro todavía fue observar cómo las IAs tendían a “pensar de más” en los ejercicios fáciles. Encontraban la respuesta correcta pronto, pero seguían explorando caminos alternativos hasta acabar escribiendo soluciones erróneas, como un estudiante brillante que borra la contestación correcta por inseguridad y la sustituye por algo descabellado al final del examen.
En los retos más complejos, en lugar de esforzarse más, los modelos reducían su esfuerzo. Aunque disponían de margen de cómputo suficiente, no incrementaban la profundidad de su razonamiento ni exploraban más alternativas; simplemente se quedaban cortos. No hay ningún “instinto de lucha” ni alarma interna que les diga “esto se me está atragantando, voy a dedicarle más recursos”.
Para las empresas que quieren basar procesos críticos en IA, el mensaje es claro: un modelo puede sonar convincente, articular explicaciones complejas y dar sensación de seguridad, pero eso no significa que esté en lo cierto, sobre todo cuando se enfrenta a situaciones nuevas o reglas de negocio intrincadas. No existe un cambio de tono, una alerta incorporada o una marca de agua que indique “esto me lo estoy inventando con alta probabilidad”.
Apple parece haber tomado nota de estas limitaciones y, en consecuencia, ha adoptado una estrategia más cauta con la integración de IA avanzada en Siri y en el sistema operativo. La compañía ha retrasado la actualización completa del asistente hasta 2026, y ha optado por apoyarse en Google Gemini para algunos de los casos de uso más complejos, manteniendo a la vez los datos realmente sensibles en el dispositivo mediante modelos locales.
Esta aproximación híbrida refleja una tensión de fondo: por un lado, el deseo de ofrecer funciones inteligentes competitivas; por otro, la conciencia de que los modelos actuales no son fiables al 100 % y que, si se les dan demasiadas riendas, pueden convertirse en fuentes de errores sutiles o brechas de seguridad muy serias.
En este contexto, el verdadero valor diferencial está en saber cuándo fiarse de la salida de una IA y cuándo ponerla en cuarentena. No basta con dominar el arte de redactar prompts o de integrar APIs; hay que aprender a detectar situaciones de alto riesgo, diseñar salvaguardas adicionales y, sobre todo, no delegar decisiones críticas a modelos que son, en esencia, excelentes generadores de texto, pero muy malos reconociendo sus propios límites.
Al final, todo lo que hemos visto alrededor del Neural Engine y Apple Intelligence apunta en la misma dirección: Apple lleva años construyendo un hardware de IA potentísimo y extremamente eficiente, pero lo hace detrás de una capa de opacidad que restringe lo que los desarrolladores pueden hacer. Cuando alguien se sale del guion y aborda el problema con ingeniería inversa, aparecen capacidades de entrenamiento local y técnicas avanzadas que la compañía no ofrece de forma oficial. Al mismo tiempo, la integración profunda de la IA en el sistema crea nuevas superficies de ataque, como han demostrado las inyecciones de prompt, y obliga a reforzar continuamente los mecanismos de seguridad.