El estudio de IA de Tech Against Terrorism concluye que las salvaguardas pueden colapsar
Tech Against Terrorism probó más de 130 modelos de IA, y tres de cada cinco no superaron su más reciente evaluación de seguridad antiterrorista. El estudio de IA de Tech Against Terrorism detectó los fallos más graves en modelos modificados cuyas salvaguardas de rechazo habían sido eliminadas deliberadamente.
Esta distinción es importante. El estudio no demuestra que la mayoría de los chatbots convencionales ayuden abiertamente a terroristas durante su uso habitual. Muestra que la seguridad puede deteriorarse rápidamente cuando los modelos se modifican, se reformulan o se distribuyen fuera del control directo de sus desarrolladores.
El resultado presiona a Meta, Hugging Face, los desarrolladores de modelos de pesos abiertos y los hosts de modelos. Su principal desafío es preservar la investigación legítima y el despliegue local sin tratar las salvaguardas del momento de lanzamiento como una protección permanente.
Por tanto, el hallazgo más contundente no es una simple competición entre IA abierta y cerrada. Es un conflicto entre modelos adaptables y controles de seguridad que podrían no sobrevivir a la adaptación.
El estudio de IA de Tech Against Terrorism amplió la prueba
La nueva evaluación desplaza el debate de fallos aislados de chatbots hacia una prueba más amplia de cómo se comporta la seguridad a lo largo de la cadena de suministro de modelos.
Tech Against Terrorism es una organización sin ánimo de lucro con sede en el Reino Unido centrada en la actividad terrorista en internet. Sus investigadores evaluaron más de 130 modelos con cientos de solicitudes relacionadas con la planificación de ataques, la financiación, la radicalización y otras formas de asistencia perjudicial.
La prueba de la organización analiza si un modelo rechaza de forma consistente solicitudes peligrosas. También considera la gravedad y especificidad de cualquier información que proporcione el modelo.
Según las pruebas ampliadas, un modelo suspendía si generaba una respuesta completa y específica sobre daños con víctimas masivas. Una puntuación inferior a 90 sobre 100 también se consideraba un fallo.
Es un umbral exigente. Un modelo puede rechazar la mayoría de los prompts peligrosos y aun así suspender porque una respuesta proporciona ayuda suficientemente completa.
Este enfoque difiere de una prueba básica de tasa de rechazo. Una tasa de rechazo cuenta con qué frecuencia un modelo dice que no, pero puede pasar por alto el cumplimiento parcial.
Algunos sistemas empiezan con una advertencia y luego proporcionan el material solicitado. Tech Against Terrorism denomina a este patrón cumplimiento con reservas.
El anterior benchmark antiterrorista de la organización examinó 27 modelos líderes y casi 2.500 prompts de un solo intento. Aproximadamente un tercio de esas respuestas ofreció ayuda significativa más allá de una búsqueda web ordinaria.
Ese piloto también detectó variaciones importantes según la categoría de amenaza y el encuadre del prompt. Una solicitud idéntica recibió un tratamiento diferente cuando el usuario alegaba un propósito de investigación.
La investigación más reciente amplió el grupo de modelos mientras se concentraba en 627 solicitudes. Su resultado principal fue que aproximadamente el 60 por ciento de los sistemas probados no alcanzó el estándar de seguridad establecido.
Las dos rondas no deberían tratarse como estadísticas intercambiables. Utilizaron conjuntos de modelos, tamaños de prueba y métricas de informe diferentes.
Sin embargo, en conjunto respaldan la misma conclusión. La seguridad aparente de un modelo depende de algo más que de su nombre, proveedor o interfaz estándar.
La configuración circundante importa. También lo hacen sus pesos, instrucciones de sistema, controles de despliegue y la identidad que afirma tener el usuario.
La evaluación incluyó declaraciones directas de intención terrorista. También probó solicitudes presentadas mediante roles menos evidentemente maliciosos, incluido un encuadre orientado a la investigación.
Esto importa porque los atacantes reales rara vez necesitan declarar sus intenciones con veracidad. Una salvaguarda que solo funciona tras una confesión clara ofrece una seguridad limitada.
El estudio también desplaza la atención de escenarios futuros abstractos a sistemas disponibles ahora. Muchos modelos probados pueden ejecutarse localmente, aparecer en repositorios públicos o ser modificados por terceros.
Esa disponibilidad crea la tensión central del artículo. Los desarrolladores pueden probar el modelo original, pero no pueden asumir que cada copia distribuida conservará el mismo comportamiento.
La verdadera división es entre acceso controlado y pesos editables
Los hallazgos no establecen que todos los modelos de pesos abiertos sean inseguros, pero exponen un problema de control que los servicios cerrados gestionan de otra manera.
Los modelos de pesos abiertos ponen sus parámetros entrenados a disposición para su descarga. Esos parámetros codifican los patrones que un sistema aprendió durante el entrenamiento y el ajuste posterior de seguridad.
Los desarrolladores pueden adaptar estos modelos a idiomas, sectores, hardware local y aplicaciones especializadas. Los investigadores pueden inspeccionar comportamientos que un servicio alojado podría ocultar.
Estos beneficios explican por qué el desarrollo de pesos abiertos ha atraído a empresas, universidades, laboratorios independientes e instituciones públicas. Puede reducir la dependencia de un pequeño grupo de proveedores de API.
Los modelos cerrados crean una configuración distinta. Los usuarios acceden a ellos mediante servicios controlados por el desarrollador del modelo, sin recibir los pesos subyacentes.
Ese control permite a un proveedor actualizar filtros, supervisar actividad sospechosa, limitar cuentas y retirar el acceso. No garantiza la seguridad, pero conserva opciones de intervención.
Un lanzamiento de pesos abiertos no puede retirarse del mismo modo. Una vez que las copias se extienden por repositorios y equipos locales, los cambios de política posteriores no pueden llegar a ellas de forma fiable.
El benchmark anterior de Tech Against Terrorism concluyó que la división principal en rendimiento no era entre abierto y cerrado. Algunos modelos abiertos convencionales figuraron entre los sistemas más seguros de esa prueba.
Claude de Anthropic y Falcon3 del Technology Innovation Institute obtuvieron posiciones altas en el piloto. MiniMax también tuvo un desempeño sólido, según la organización.
Ese resultado complica las afirmaciones de que la apertura por sí sola determina el peligro. Los modelos abiertos bien alineados pueden rechazar solicitudes perjudiciales, mientras que los servicios controlados todavía pueden generar respuestas inseguras.
La división más relevante aparece después del lanzamiento. Los usuarios pueden alterar el comportamiento de rechazo de un modelo de pesos abiertos sin la aprobación del desarrollador original.
Meta afirma que Llama 3.1 pasó por evaluaciones de riesgo previas al despliegue, pruebas adversariales, ajuste de seguridad y ejercicios externos de red team. Su plan de lanzamiento responsable también describe salvaguardas a nivel de modelo y de sistema.
Estas medidas siguen siendo importantes. Según los informes, la versión base probada de Llama 3.1 8B obtuvo 97 sobre 100 en el benchmark de la organización sin ánimo de lucro.
La versión modificada obtuvo aproximadamente tres. Esa caída de 94 puntos es el ejemplo más claro de controles de seguridad que no acompañan al modelo.
Las políticas de Meta prohíben los usos perjudiciales e ilegales. Sin embargo, las normas de uso restringen más eficazmente a los usuarios que las cumplen que a los adversarios que poseen archivos de modelo editables.
Esto no vuelve irrelevantes las políticas. Proporcionan fundamentos para la aplicación de normas en despliegues comerciales, plataformas y licenciatarios identificables.
No obstante, la aplicación de políticas se debilita cuando un modelo funciona sin conexión. Un sistema local no necesita enviar prompts al proveedor original.
La presión resultante va más allá de Meta. Todo desarrollador que publique pesos editables debe decidir qué propiedades de seguridad pertenecen al interior del modelo y cuáles dependen de controles de despliegue.
El estudio sugiere que el ajuste de rechazo por sí solo no puede soportar toda la carga. Los desarrolladores también necesitan evaluaciones diseñadas en torno a la modificación posterior al lanzamiento.
Los hosts de modelos afrontan un problema relacionado. Deben distinguir los artefactos de investigación de los sistemas anunciados específicamente para un uso sin restricciones.
Esta distinción es difícil de automatizar. Un modelo modificado puede respaldar una investigación legítima sobre seguridad, trabajo creativo o pruebas, al tiempo que elimina barreras contra la asistencia perjudicial.
Las prohibiciones amplias impondrían costes a investigadores y desarrolladores más pequeños. Los controles de distribución débiles dejarían modelos claramente desrestringidos fáciles de encontrar.
Por eso, el conflicto principal es entre capacidad adaptable y seguridad duradera. La cuestión no es si deberían existir modelos abiertos.
La cuestión es qué protecciones pueden seguir siendo eficaces después de que el desarrollador pierda el control directo.
Abliteration convierte el entrenamiento de rechazo en una capa eliminable
Abliteration importa porque se dirige directamente al comportamiento de rechazo, transformando una salvaguarda del momento de lanzamiento en una característica que terceros pueden eliminar.
Abliteration es una técnica de modificación de modelos que identifica patrones internos asociados al rechazo de solicitudes perjudiciales. Después, suprime o contrarresta esos patrones.
La técnica no añade necesariamente conocimiento nuevo. En cambio, cambia si el modelo revelará conocimientos que ya adquirió durante el entrenamiento.
Esta distinción es crucial. Un sistema puede conservar las mismas capacidades generales y, al mismo tiempo, estar mucho más dispuesto a responder solicitudes peligrosas.
Tech Against Terrorism informó de que los modelos sometidos a abliteration suspendieron todas las pruebas de seguridad del estudio más reciente. Los investigadores también descubrieron que modelos más pequeños podían modificarse en cuestión de minutos con herramientas disponibles gratuitamente.
La organización probó una versión alterada de Llama 3.1 8B de Meta frente al original. El modelo base rechazó solicitudes relacionadas con ataques, financiación terrorista y radicalización.
Según los informes, la versión modificada proporcionó respuestas detalladas. Los investigadores no afirmaron que esas respuestas permitieran automáticamente un ataque real.
Su benchmark mide si un sistema entrega la información solicitada. No establece si un usuario puede ejecutar esa información con éxito.
Esta limitación no elimina el hallazgo. Define lo que la prueba puede respaldar.
El experimento muestra un gran cambio en el comportamiento de divulgación. No mide la competencia del usuario, su acceso a materiales, su seguridad operativa ni su capacidad de superar barreras prácticas.
La capa de repositorios de modelos agrava este problema. Tech Against Terrorism identificó más de 29.000 repositorios de Hugging Face que anunciaban modelos como sin censura o sin salvaguardas.
Esa cifra no significa que los 29.000 repositorios contuvieran material terrorista. Describe cuántos proyectos empleaban etiquetas que sugerían restricciones reducidas.
Algunos repositorios pueden duplicar el mismo modelo. Otros pueden usar “uncensored” como un término amplio de marketing sin haber pasado por la técnica específica probada aquí.
Incluso con estas salvedades, la cifra ilustra lo difícil que se vuelve el control a nivel de modelo después de su distribución. Las copias pueden multiplicarse más rápido de lo que los investigadores pueden evaluarlas.
Hugging Face dijo a CBS News que realiza una moderación continua y actúa contra modelos, conjuntos de datos y aplicaciones que incumplen sus normas.
Su política de contenido de la plataforma restringe el contenido terrorista y permite varias respuestas. Estas incluyen la retirada de acceso, la restricción de repositorios, los límites de visibilidad y la suspensión de cuentas.
Hugging Face también advirtió que partes de la respuesta propuesta por el informe podrían restringir el trabajo científico abierto. Esta preocupación merece una consideración seria.
Los investigadores de seguridad necesitan acceso a artefactos inseguros para estudiar modos de fallo. Los desarrolladores también necesitan modelos adversariales para probar filtros y sistemas de supervisión.
Por tanto, un repositorio puede ser peligroso en un contexto y valioso en otro. Las etiquetas por sí solas no pueden resolver la cuestión.
El diseño de acceso ofrece una vía más específica. Las plataformas pueden aplicar verificación de identidad, restricciones de acceso, etiquetas de advertencia, supervisión de descargas o resultados de pruebas independientes según el riesgo demostrado.
Estos controles son imperfectos. Una vez descargado un modelo, la plataforma pierde gran parte de su capacidad de influencia.
Sin embargo, la fricción en la distribución puede cambiar la escala. Puede impedir que los sistemas de recomendación conviertan modificaciones de alto riesgo en descubrimientos casuales.
Por tanto, el estudio plantea un problema de cadena de suministro. El desarrollador original crea un modelo, otra parte elimina sus negativas y una plataforma distribuye el resultado.
Cada participante controla solo una parte del proceso. Sin embargo, el público experimenta el riesgo combinado.
Una respuesta duradera debe abordar las tres capas. Un entrenamiento más seguro no puede sustituir la gobernanza de repositorios, y la gobernanza de repositorios no puede reparar todos los modelos.
La supervisión del despliegue también sigue siendo esencial. Las organizaciones que ejecutan modelos abiertos necesitan sus propios filtros, registros, permisos y procedimientos de incidentes.
Una empresa no debe asumir que la puntuación de seguridad publicada del modelo base se mantiene tras el ajuste fino. Toda modificación sustancial crea un nuevo objetivo de evaluación.
Las pruebas de seguridad sobre terrorismo con IA aún tienen una brecha de verificación
El estudio identifica una grave debilidad de seguridad, pero no demuestra un uso operativo generalizado por parte de organizaciones terroristas.
Tech Against Terrorism afirmó no haber encontrado pruebas de que grupos terroristas o extremistas estuvieran utilizando los modelos evaluados. Durante la investigación identificó un chatbot extremista.
Esa brecha de verificación es la limitación más importante del titular. La disponibilidad del modelo, las respuestas inseguras y la adopción operativa representan etapas distintas.
Un modelo puede responder a una pregunta perjudicial sin mejorar la capacidad de un actor real. Gran parte de esa información puede ya existir en libros, foros o resultados de búsqueda.
La medida relevante es el incremento de capacidad. Es decir, si el modelo facilita de forma significativa una actividad perjudicial frente a las alternativas disponibles.
Tech Against Terrorism diseñó su piloto en torno a esa cuestión. Los investigadores compararon la ayuda del modelo con el material que una persona capacitada podría obtener mediante búsquedas web ordinarias.
Sus resultados de julio indicaron que aproximadamente un tercio de las respuestas generaba un incremento de capacidad significativo. El estudio ampliado más reciente utilizó un umbral más estricto de fallo a nivel de modelo.
Ninguno de los dos resultados debe traducirse en un número previsto de ataques. El parámetro de referencia no proporciona esa estimación causal.
Analistas independientes también han advertido contra centrarse únicamente en escenarios espectaculares. Un análisis de riesgo terrorista del Center for Strategic and International Studies sostuvo que los efectos a corto plazo podrían ser más graduales.
La IA puede ayudar con propaganda, traducción, reclutamiento, investigación, reconocimiento y tareas administrativas. Estos usos pueden importar sin producir un arma autónoma novedosa.
Esta asistencia de menor nivel es más difícil de detectar. También se parece lo suficiente a actividades legítimas como para complicar la moderación.
El revisor independiente de la legislación antiterrorista del Reino Unido llegó a una visión igualmente amplia. La revisión de riesgos legales abordó propaganda, radicalización, planificación de ataques y asistencia relacionada con armas.
La revisión identificó la radicalización impulsada por chatbots como un problema jurídico especialmente difícil. No sugirió que cada intercambio riesgoso requiriera un nuevo delito específico para la IA.
Estas distinciones deben orientar la forma en que los lectores interpretan la cifra del 60 por ciento. Es un resultado de evaluación, no una medición de la adopción terrorista actual.
El umbral de fallo también premia la consistencia. Una respuesta detallada puede hacer que un modelo falle incluso si rechaza cientos de otras solicitudes.
Ese estándar tiene sentido para una seguridad de consecuencias graves. Una sola revelación seria puede importar más que una elevada tasa media de rechazos.
Sin embargo, no demuestra que todos los modelos que fallan planteen el mismo riesgo. Los modelos difieren en precisión, capacidad, distribución, requisitos de hardware y utilidad práctica.
Un pequeño modelo local podría acceder fácilmente a colaborar, pero proporcionar información poco fiable. Un sistema de frontera podría ofrecer mejor información mientras opera tras controles de acceso más sólidos.
El estudio también depende de la selección de prompts y de criterios de evaluación. Los parámetros de referencia antiterroristas deben decidir qué solicitudes son perjudiciales y qué se considera asistencia significativa.
Los falsos positivos pueden restringir la investigación legítima sobre seguridad, el periodismo, la educación y el análisis histórico. Los falsos negativos pueden dejar sin detectar asistencia peligrosa.
La replicación independiente reforzaría los hallazgos. Los investigadores deberían publicar suficiente metodología para que los expertos examinen las definiciones de categorías y la fiabilidad de la puntuación.
Deben hacerlo sin divulgar una colección lista para usar de prompts perjudiciales. Esto crea un dilema conocido en la investigación sobre seguridad.
El público necesita pruebas de que el parámetro de referencia mide el riesgo real. Sin embargo, una divulgación excesiva puede convertir un paquete de evaluación en una guía para el abuso.
Por ello, la conclusión correcta debe ser mesurada pero firme. La investigación demuestra controles de negativa frágiles en muchos de los sistemas evaluados.
No establece que la IA ya haya transformado las capacidades terroristas a gran escala. Muestra que las condiciones para el uso indebido son cada vez más fáciles de reunir.
Los desarrolladores y los alojadores de modelos ahora comparten la carga de la seguridad
Los hallazgos presionan a la industria de la IA para que trate la seguridad como una propiedad continua, no como un certificado emitido cuando se lanza un modelo base.
Tech Against Terrorism quiere que los gobiernos y los desarrolladores respalden evaluaciones independientes antes del lanzamiento. También recomienda diseñar modelos que resistan la eliminación de salvaguardas.
Para las plataformas de distribución, el grupo propone restricciones sobre modelos modificados que no superen pruebas independientes. También ha sugerido acceso verificado para artefactos especialmente riesgosos.
Estas propuestas abordan distintas partes de la misma cadena de fallos. Ninguna intervención por sí sola puede impedir toda modificación local o transferencia privada.
Los desarrolladores pueden empezar evaluando comportamientos específicos de amenazas. Los conjuntos generales de pruebas de seguridad pueden no captar escenarios de financiación terrorista, radicalización o preparación de ataques.
El piloto detectó una protección desigual entre categorías. Los modelos rechazaron las solicitudes conocidas sobre explosivos de forma más consistente que algunas solicitudes relacionadas con otras armas o vías de adquisición.
Un promedio general puede ocultar esas brechas. Las pruebas deberían informar el rendimiento por categoría y la gravedad de las revelaciones exitosas.
Los desarrolladores también deberían evaluar el encuadre de identidad. El parámetro de referencia anterior detectó que presentar la misma solicitud como investigación aumentaba sustancialmente el cumplimiento.
Ese resultado indica un atajo de clasificación. El modelo reacciona a un rol declarado en lugar de evaluar la capacidad solicitada y el daño probable.
Un mayor ajuste de negativas podría reducir esta debilidad, pero también corre el riesgo de bloquear trabajo legítimo. Los controles de acceso sensibles al contexto podrían ofrecer un mejor equilibrio.
Un investigador verificado podría recibir información no disponible para un usuario anónimo. Tales sistemas requerirían una autorización responsable y registros de auditoría.
Las publicaciones de pesos abiertos dificultan una autorización centralizada. Los desarrolladores podrían centrarse en reducir el conocimiento peligroso, mejorar la resistencia a la manipulación y incluir herramientas de despliegue más robustas.
Ninguna de estas medidas ofrece una respuesta completa. Filtrar los datos de entrenamiento puede reducir conocimiento científico útil, mientras que la resistencia a la manipulación puede obstaculizar modificaciones legítimas.
La evaluación independiente ayuda a exponer esas compensaciones. Ofrece a compradores y alojadores pruebas que van más allá de las propias afirmaciones de seguridad de un desarrollador.
Los repositorios de modelos pueden contribuir mostrando resultados de evaluación estandarizados. Los usuarios deberían saber si una descarga conserva las salvaguardas del modelo base.
Las plataformas también pueden separar la personalización ordinaria de la eliminación explícita del comportamiento de negativa. Un modelo promocionado por sortear protecciones merece un examen más riguroso.
La restricción de acceso no debería convertirse en un paso meramente cosmético. Los controles eficaces necesitan condiciones aplicables, revisión basada en riesgos y vías claras para la investigación legítima.
Los responsables de despliegues empresariales asumen la capa final de responsabilidad. Ellos eligen los prompts de sistema, las fuentes de recuperación, las herramientas, los permisos y el acceso de usuarios.
Un modelo base seguro puede volverse inseguro cuando se conecta a bases de datos sensibles o acciones del mundo real. Un modelo modificado puede generar exposición adicional incluso sin acceso a herramientas.
Los equipos de seguridad deberían evaluar el sistema desplegado en lugar de depender de una tarjeta de modelo. El ajuste fino, la cuantización y los adaptadores de terceros pueden alterar el comportamiento.
Los equipos de compras deberían preguntar si los proveedores prueban el uso indebido específico para terrorismo. También deberían preguntar cómo detectan los proveedores las salvaguardas que desaparecen tras la personalización.
Los gobiernos se enfrentan al equilibrio más difícil. Las normas centradas demasiado estrechamente en la publicación pueden centralizar el desarrollo de IA sin eliminar los modelos perjudiciales que ya están en línea.
Las normas centradas solo en el uso indebido posterior llegan después de la distribución. También pueden depender de investigaciones que empiezan solo después de que se produzca el daño.
Un marco viable necesitará controles proporcionales. La capacidad del modelo, el tipo de modificación, el método de acceso y el desempeño demostrado en seguridad deberían influir en la respuesta.
El debate no puede reducirse a modelos abiertos frente a modelos cerrados. Ambos enfoques crean riesgos, incentivos y brechas de rendición de cuentas.
Los proveedores cerrados pueden supervisar a los usuarios, pero concentran el control. El desarrollo abierto respalda el escrutinio y la competencia, pero dificulta la intervención tras el lanzamiento.
La contribución del estudio consiste en hacer concreta esa compensación. Las afirmaciones de seguridad deben resistir la ruta real del modelo, desde el desarrollador hasta el alojador y el usuario.
Qué observar después del estudio de IA de Tech Against Terrorism
La siguiente fase revelará si la industria trata estos resultados como un problema de evaluación, un problema de distribución o ambos.
La primera señal es la replicación independiente. Otros laboratorios deberían comprobar si la tasa de fallos reportada se mantiene en nuevos modelos, idiomas y conversaciones de varios turnos.
La replicación podría reforzar las conclusiones del estudio si los investigadores observan descensos similares tras eliminar salvaguardas. Grandes diferencias revelarían sensibilidad a la puntuación o al diseño de los prompts.
La segunda señal es la política de los repositorios. Hugging Face y otros alojadores deben decidir cómo clasifican, etiquetan, restringen o eliminan modelos deliberadamente desrestringidos.
Una respuesta significativa distinguiría la investigación legítima sobre seguridad de la distribución masiva sin restricciones. Una política general de eliminación podría, en cambio, llevar los modelos a canales menos responsables.
La tercera señal son las pruebas de los desarrolladores. Meta y otros editores de pesos abiertos pueden añadir evaluaciones posteriores a modificaciones a sus procesos de lanzamiento.
Esas pruebas deberían examinar si los métodos habituales de ajuste fino o eliminación de negativas modifican el comportamiento de consecuencias graves. Los resultados públicos harían más fácil evaluar posteriores afirmaciones de seguridad.
Los lectores también deberían estar atentos a pruebas de adopción en el mundo real. La limitación más importante del informe actual es la ausencia de uso demostrado por grupos terroristas.
Los incidentes verificados aumentarían la urgencia de los controles de distribución. La ausencia continuada de tales pruebas respaldaría medidas más específicas frente a restricciones generales.
Ningún resultado haría irrelevante la seguridad de los modelos. La prevención suele comenzar antes de que una nueva herramienta se vuelva habitual.
La lección práctica para los desarrolladores es inmediata. No traten el comportamiento de negativa de un modelo base como una propiedad permanente.
Las organizaciones deberían volver a ejecutar evaluaciones de seguridad después del ajuste fino, la cuantización, cambios en los prompts de sistema o la instalación de adaptadores. Deberían probar todo el sistema desplegado antes de conceder acceso sensible.
Los investigadores deberían seguir examinando cómo fallan las barreras de seguridad sin convertir esos hallazgos en instrucciones operativas. Las plataformas deberían crear sistemas de revisión que reconozcan esa distinción.
Los responsables políticos deberían exigir resultados de seguridad medibles mientras preservan el análisis legítimo. Las garantías vagas y las prohibiciones generales eluden por igual el difícil trabajo de ingeniería.
El estudio de Tech Against Terrorism sobre IA no resuelve el futuro de la IA de pesos abiertos. Plantea una pregunta más práctica para cada lanzamiento.
¿Pueden las protecciones de seguridad de un modelo sobrevivir a los cambios que lo vuelven útil, portátil y abierto a la experimentación?
Los desarrolladores, los proveedores de alojamiento y los compradores deberían plantearse esa pregunta antes de que el próximo modelo se extienda por miles de repositorios. Si la respuesta sigue sin estar clara, las pruebas independientes deberían ser la primera medida.
