¿Puede un asistente de IA local diagnosticar un fallo sin tener acceso a toda la red?
Transit abre su código y permite elegir un modelo local o alojado. Los comandos, las credenciales y los datos que cruzan ese límite determinan qué puede investigar con seguridad.
Una sucursal informa de que sus teléfonos pueden hacer llamadas, pero no siempre las reciben. El equipo de red ve un cambio en una interfaz, un evento de enrutamiento y varias conexiones que agotan su tiempo de espera. Un asistente podría ordenar esas observaciones y proponer el siguiente comando de solo lectura. Elegir el modelo es solo una parte del trabajo. El operador también necesita saber qué credenciales puede usar la herramienta, qué texto sale del equipo y si el modelo puede provocar cambios.
Transit es una herramienta de diagnóstico de redes que incorporó su cliente al proyecto de código abierto con licencia Apache 2.0 el 21 de octubre de 2026. Su página de transición fijó el 5 de noviembre como fecha límite del acceso anual y señala el 17 de noviembre como fecha prevista para el cambio del servicio de IA alojado. Esas fechas corresponden a la transición comercial. La disponibilidad del software y el estado de una cuenta alojada concreta son cuestiones distintas. Las versiones publicadas, el archivo README y la documentación de funciones son las mejores referencias para la compilación que el equipo vaya a probar.
Qué significa «local» en una investigación de red
Selección del punto de conexión del modelo. Ilustración original de Telli.sh.
El cliente puede usar Ollama u otro punto de conexión compatible con OpenAI. La documentación también contempla el uso de una clave propia de OpenAI o Anthropic y una opción preliminar de inicio de sesión para cuentas de ChatGPT Plus o Pro que cumplan los requisitos. Con un servidor de Ollama en el mismo equipo, la inferencia puede quedarse en él. Si Transit apunta a un servidor de la empresa, los datos se envían a ese servidor. Si se elige un proveedor en la nube, la solicitud se envía al proveedor después de ocultar datos según el procedimiento que documenta el proyecto.
Por otra parte, el cliente necesita llegar a los equipos de red para recopilar pruebas. Una investigación puede pasar por un servidor de salto, una cuenta de operador de solo lectura y varios dispositivos. La ubicación del modelo no determina a qué dispositivos puede llegar el cliente. Lo determinan la conectividad de red y los permisos de las credenciales.
El repositorio documenta un conjunto reducido de herramientas y una lista de comandos permitidos para los fabricantes compatibles. También describe una política de aprobación de comandos. El operador puede configurar la aprobación automática en sistemas compatibles para los casos que coincidan con una regla habilitada. El enmascaramiento de datos y el filtrado de comandos son capas distintas que se pueden probar. Trata los mensajes de bienvenida de los dispositivos y los registros como texto no fiable, sobre todo si contienen frases imperativas. El asistente puede resumirlos sin asumir que contienen instrucciones autorizadas.
| Límite | Pregunta para el operador | Prueba útil |
|---|---|---|
| Punto de conexión del modelo | ¿A dónde se envía la petición completa? | Inspeccionar los destinos con un caso ficticio |
| Acceso a los equipos | ¿A qué dispositivo y cuenta puede llegar la herramienta? | Probar en el laboratorio un host conocido que esté fuera del alcance autorizado |
| Aprobación de comandos | ¿Quién puede aprobar una acción propuesta? | Rechazar un comando y confirmar que el dispositivo no lo ejecuta |
| Pruebas y registros | ¿Qué datos se conservan o salen del equipo? | Usar valores marcadores inocuos y revisar las exportaciones |
Conmutadores y paneles del tipo que inspeccionan los operadores. Fotografía de contexto de Dsimic, recortada y redimensionada, CC BY-SA 4.0. Fuente de la imagen · Licencia.
Una prueba piloto con un fallo conocido
Investigación de red. Ilustración original de Telli.sh.
Prepara un pequeño laboratorio con un problema de enrutamiento o de interfaz conocido. Dale a la herramienta una cuenta con los permisos mínimos en el dispositivo previsto e incluye un host ajeno que deba permanecer inaccesible. Pide una hipótesis y una lista breve de observaciones que puedan refutarla. Revisa uno de los comandos de consulta propuestos y ejecútalo. Compara la salida con la misma observación obtenida manualmente.
En una segunda ejecución, presenta un síntoma ambiguo. Un servicio lento puede encajar con problemas en varias rutas de red, y un comando de un dispositivo real puede exponer identificadores de clientes. Los marcadores ficticios permiten comprobar dónde se envía, registra o conserva la salida. Mantén separada la conectividad del laboratorio y la del servidor de salto de producción hasta que los operadores entiendan qué expone cada modo.
Al exportar el resultado, adjunta el comando, la hora, la identidad del dispositivo y la salida pertinente a la hipótesis que respaldan. Así el operador puede revisar la cadena de pruebas sin tener que recordar qué frase salió de un router y cuál del modelo.
Integridad de las versiones y límites del modelo local
Transit indica que sus compilaciones publicadas no están firmadas. El archivo SHA256SUMS de cada versión permite verificar si la descarga coincide con el resumen publicado. Esa comparación por sí sola no autentica a quien la publica. Los equipos que necesiten artefactos firmados pueden valorar compilar una etiqueta revisada mediante su propio proceso de distribución de software. La documentación del instalador de Windows también exige PowerShell 7.
La inferencia local reduce la dependencia de un proveedor en la nube y puede encajar donde se limita el intercambio de datos. Un modelo local más pequeño puede pasar por alto el contexto, interpretar mal las salidas de distintos fabricantes o tardar más con el hardware disponible. Si ambas configuraciones están permitidas, prueba el mismo caso conocido con un modelo local y con uno alojado que esté aprobado. Mide las hipótesis correctas, los comandos innecesarios, las asociaciones erróneas entre dispositivos y el tiempo total del operador.
Un objetivo razonable para el primer uso es un recopilador de pruebas con un alcance definido, con las aprobaciones automáticas desactivadas y una persona revisando cada comando propuesto. Si las pruebas de laboratorio ofrecen resultados consistentes y un informe que se pueda defender, la siguiente decisión es qué tipos de investigación de solo lectura pueden seguir ese proceso en producción. Esa pregunta es más concreta y útil que decidir si el modelo debe tener acceso general a la red.
Instala una compilación concreta y documenta sus límites
La versión v6.5.11 corrige una discrepancia en los nombres del manifiesto de sumas de comprobación para que las entradas coincidan con los nombres de archivo normalizados por GitHub. Elige de forma deliberada la versión y la plataforma y comprueba la suma publicada antes de ejecutar el instalador. Lee las notas de la versión y descarga los archivos desde el repositorio oficial. Si tu organización distribuye el software aprobado mediante un catálogo gestionado, sigue ese procedimiento. La coincidencia del resumen comprueba el archivo y el catálogo determina si se autoriza su instalación.
El README describe seis herramientas de investigación. Que sean pocas sirve de algo si el operador sabe hasta dónde llega cada una. Anota el punto de conexión del modelo, el servidor de salto y el único conmutador de prueba antes de conceder credenciales. Registra qué cuenta abrió cada conexión. Si un desarrollador configura un servidor de Ollama aparte, comprueba a qué dirección se conecta el cliente. Desde el punto de vista del portátil, un servicio en la red de la oficina sigue siendo un destino externo.
- Crea un caso de laboratorio con un síntoma conocido y una cuenta limitada a los equipos previstos.
- Verifica la compilación elegida y revisa el punto de conexión, las credenciales y los ajustes de conservación.
- Pide al asistente la próxima observación y una hipótesis que esa observación pueda refutar.
- Con la aprobación automática desactivada, rechaza una propuesta y consulta el registro del dispositivo antes de permitir otro comando seguro.
- Introduce marcadores inocuos en los registros de ejemplo. Comprueba si el cliente los oculta y dónde aparecen en los registros locales o en el punto de conexión configurado.
- Exporta los hallazgos y pide a otro operador que reproduzca el diagnóstico con las pruebas registradas.
Si se cambia de proveedor de vez en cuando, conviene repetir el ejercicio después de cambiar la configuración. El mismo botón puede activar una ruta de datos diferente si cambia el destino. La observación del tráfico en un laboratorio autorizado permite comprobarlo. Una captura de la configuración por sí sola no acredita qué destino recibió una solicitud.
Separa los conmutadores compatibles de un intérprete genérico
El modelo de amenazas de Transit para esa etiqueta describe una política de comandos para los fabricantes compatibles, con aprobación automática opcional si coincide con una regla habilitada con anterioridad. En un piloto se puede mantener desactivada y hacer que el operador revise cada propuesta. La herramienta sigue necesitando una cuenta de dispositivo con un alcance reducido. Un cuadro de aprobación no reduce los permisos efectivos de una cuenta de servicio.
El mismo documento describe una política diferente para Linux y Unix genéricos. Esa ruta avisa al operador, exige aprobación para cada comando y carece de una regla de permiso permanente. La política subyacente de comandos en sistemas genéricos no restringe el conjunto de comandos. Deja esa modalidad fuera del piloto inicial de solo lectura salvo que la organización pueda imponer el alcance de forma independiente. La clase de dispositivo y la cuenta forman parte del diseño de seguridad.
Un segundo caso de laboratorio puede evaluar qué hace la herramienta al encontrarse una salida desconocida. Un comando puede mostrar un contador que el modelo no reconoce, o dos fabricantes pueden dar nombres distintos a la interfaz esperada. Una respuesta útil cita la observación original y pide una comprobación que permita distinguir hipótesis. Una respuesta peor toma una interpretación plausible como un hecho comprobado. Los operadores pueden valorar ambas sin exponer equipos de producción.
Prepara la exportación para el turno siguiente
Un diagnóstico en una línea es cómodo para quien investigó el incidente. El relevo requiere la última observación confirmada, qué se descartó, qué sigue siendo incierto y qué puede comprobar la persona que entra sin reabrir todas las sesiones. Añade una referencia a las pruebas junto a cada afirmación importante. Si el modelo cambia el diagnóstico tras ver un registro nuevo, explica el motivo.
La comparación debe incluir el proceso manual que ya usa el equipo. Registra el tiempo hasta la primera observación útil, cuántos comandos irrelevantes se proponen y cuánto se tarda en redactar el relevo. Un modelo local puede ofrecer una ventaja de privacidad si resuelve el trabajo a una velocidad aceptable. Uno alojado y aprobado puede ser más práctico en un caso difícil si la política de datos lo permite. Deja claras las rutas de conexión y las pruebas obtenidas en ambos casos.
Registra cada destino por separado
Una ficha de configuración útil indica qué envía la interfaz, qué se remite a la inferencia y qué se recoge de los equipos. Eso facilita la revisión cuando cambia el proveedor. Considera por separado la conservación en cada destino. Borrar el historial local de sesiones no demuestra que el servidor remoto haya descartado una solicitud anterior.
| Modalidad | Destino de inferencia | Una comprobación útil |
|---|---|---|
| Ollama en la misma estación de trabajo | Dirección de bucle local | Confirmar que el proceso se conecta al servicio local previsto |
| Servidor de inferencia de la empresa | Dirección interna | Verificar la autenticación del servicio y la conservación de solicitudes |
| Proveedor alojado | Punto de conexión del proveedor aprobado | Comprobar el enmascaramiento y la política con datos ficticios |
| Inicio de sesión preliminar | Cuenta elegible del proveedor | Verificar la cuenta correcta y los controles administrativos disponibles |
La tabla recoge configuraciones habituales. El equipo debe observar los destinos reales y la configuración del servicio que elija. Un administrador puede ver la misma marca en el panel tanto para un servicio alojado como para una pasarela privada. Identificar el nombre real del host y su operador permite auditar el flujo de datos.
Comprueba el enmascaramiento con pruebas sintéticas
Crea un registro de laboratorio con una dirección IP ficticia, una etiqueta de dispositivo inventada y un marcador que se parezca a un identificador de cliente. Indica qué elementos deben conservarse, ocultarse o eliminarse según la política. Usa la misma muestra en dos operaciones, por ejemplo un resumen en el chat y una exportación. El sistema puede construir esas salidas de forma diferente. Revisa cada canal antes de permitir datos reales.
En una segunda prueba, incluye el marcador en una descripción larga o una salida con formato. Una regla puede ocultar un campo conocido y pasar por alto ese mismo valor dentro de una frase. Si el resultado sigue enviando el marcador a un destino no autorizado, cierra esa vía antes de conectar equipos de producción. El operador puede reducir el conjunto de datos original y repetir la prueba para ver qué protección funciona de verdad.
Vuelve a evaluar el comportamiento después de actualizar
Tras actualizar el cliente, anota el proveedor seleccionado y repite los mismos casos de laboratorio. Los cambios en la lista de comandos permitidos o en las reglas de aprobación automática pueden afectar a las propuestas de la herramienta. Cambiar los destinos predeterminados puede alterar el recorrido de las pruebas. Verifica juntos un comando rechazado, un caso de enmascaramiento y un diagnóstico conocido que deba salir bien. Ese pequeño conjunto de regresión ayuda a operar la herramienta de código abierto a medida que cambia el entorno del equipo.
Comprueba por separado las herramientas y la cuenta del dispositivo
Una herramienta de lectura puede devolver metadatos de un dispositivo o pruebas ya disponibles. Una herramienta de ejecución puede solicitar observaciones nuevas con una cuenta conectada. Pedir un resumen debería seguir siendo posible cuando la ejecución no está disponible. Comprueba ese límite desconectando el dispositivo y dejando activo el punto de conexión del modelo. La respuesta debe distinguir entre una observación anterior y otra nueva que no se ha podido recoger.
Conecta luego una cuenta que pueda consultar un conmutador, pero que no pueda entrar en el modo de configuración ni alcanzar otro segmento. El equipo puede probar la vía rechazada en su laboratorio sin pedir al asistente un cambio real. Compara el registro de acciones propuestas por la aplicación con las entradas de acceso y comandos del dispositivo. El ejercicio separa la decisión que toma la política de la herramienta de los permisos efectivos de la cuenta.
Fuentes
-
Modelo de amenazas de Transit para la etiqueta de la versión
-
Repositorio comunitario de Transit e instrucciones sobre versiones
Para guardar un registro en el que puedas buscar las conversaciones y decisiones de tu trabajo, crea una cuenta en Telli.sh.