Cómo construí un asistente personal de IA que tiene que mostrar su trabajo
Por Chrysti Reichert | Un caso práctico de My AI Evolution
El primer diseño de mi guía Practical AI Safety llegó con detalles verdes y títulos con serifas. Mi marca usa naranja y fuentes del sistema.
Buen diseño. Marca equivocada.
Había pedido una guía sobre cómo revisar la IA. La IA me dio una razón para revisarla.
Le pedí que ajustara la guía a mi marca. El diseño se corrigió siguiendo las normas escritas y después se revisó en el sitio publicado. Yo detecté la diferencia. La asistente no la detectó por mí.
Ese detalle importa. Podría contar esto como una historia sobre mi asistente corrigiendo su trabajo y quitarme de en medio. Sonaría más impresionante. También dejaría fuera a la persona que vio el problema.
Así empieza esta historia. Con el naranja. Y con una asistente que ya tenía las instrucciones.
Los agentes llegaron con archivos separados
Antes escribí sobre una tarea que les di a cinco agentes de IA: crear un cuestionario para que alguien entendiera sus habilidades con la IA. Entregaron cinco archivos separados. Cada uno había hecho su parte, sin unir el trabajo para crear lo que yo había pedido.
Tenía un equipo. También tenía el trabajo de armar la tarea del equipo.
Añadí coordinación: quién trabajaba con quién, quién cuestionaba una suposición y dónde intervenía yo. Esa experiencia se convirtió en mi publicación sobre agentes de IA que se ignoran entre sí. Lo útil fue el fallo. Darles el mismo objetivo a varios agentes no les había dado una forma compartida de terminarlo.
Mi sistema operativo está construido alrededor de problemas como ese. La asistente necesita más que una tarea. Necesita encontrar las instrucciones vigentes, trabajar dentro de esos límites y traerme algo que pueda revisar.
Qué quiero decir con un sistema operativo personal de IA
Mi sistema operativo personal de IA es un conjunto de archivos de trabajo, instrucciones, herramientas y comprobaciones que le da a mi asistente una forma consistente de manejar mi trabajo. La llamo Deb. El sistema operativo le dice a Deb dónde buscar, qué puede hacer, cuándo me necesita y qué pruebas deben acompañar la afirmación de que algo está terminado.
Es una configuración construida alrededor de herramientas de IA. No reemplaza Windows y no entrené un modelo de lenguaje nuevo.
La diferencia importa si quieres crear tu propio asistente de IA. Una personalidad le da a la conversación una voz familiar. Un sistema de trabajo también necesita un lugar para guardar las decisiones vigentes, una forma de encontrarlas y límites sobre lo que la asistente puede hacer con ellas.
Construí el mío alrededor de una pregunta: cuando la asistente dice que algo es cierto o está terminado, ¿qué puedo revisar?
Dale un lugar a cada dato
Mi configuración asigna una fuente a cada tipo de información. Las reglas de marca van con las reglas de marca. Los servicios actuales tienen su propia fuente. Las decisiones tienen un registro. Un resumen puede ayudar a encontrar el archivo correcto, pero la asistente debe comprobar la afirmación en el archivo que lleva ese tema.
Sí, parte de mi configuración de IA consiste en archivar. Muy futurista. El archivo importa porque quien abre el cajón puede escribir una respuesta convincente usando el documento equivocado.
Un borrador viejo puede contener una decisión vieja. Una instrucción recordada puede haber sido reemplazada. Un resultado de búsqueda puede señalar el tema correcto sin contener la respuesta actual. Mis instrucciones exigen que la asistente siga esas pistas hasta la fuente antes de tratarlas como datos vigentes.
El error de marca muestra el límite. Tener una fuente no garantiza que la asistente la consulte en el momento adecuado ni que la aplique bien. La fuente dio un destino claro a la corrección. No evitó el primer error.
Encuéntralo. Revísalo. Úsalo.
Leer el diagrama como texto
Encuentra la pista
Una nota guardada o un resultado de búsqueda señala el tema.
Revisa la fuente
Abre el archivo vigente que lleva ese dato o decisión.
Respeta el límite
Si faltan pruebas, conserva la incertidumbre.
Separa lo que la asistente sabe de lo que supone
Uso estados explícitos de evidencia en las reglas de trabajo. Algo registrado, leído o encontrado tiene un peso distinto de algo supuesto o desconocido.
Una suposición puede servir al preparar un borrador. Debe seguir visible como suposición. No debe convertirse en permiso para actuar ni en un hecho dentro de un texto público.
Por ejemplo, imagina una asistente que no puede abrir un informe. La respuesta honesta es que no pudo revisarlo. No puede convertir esa falta de acceso en una afirmación de que el informe no contenía nada. El ejemplo es hipotético, pero esa distinción forma parte de mi diseño real.
Por eso también quiero pruebas ligadas a cada afirmación concreta. Revisar una página con éxito dice algo sobre esa página. No demuestra que todos los procesos relacionados funcionen.
Dale espacio para trabajar y un punto claro donde detenerse
Una asistente que pide permiso para corregir cada frase agota. Una que interpreta un pedido de borrador como permiso para publicarlo es otro problema.
Mis reglas distinguen la preparación de las acciones hacia afuera. La investigación, los borradores y el trabajo local reversible pueden avanzar dentro de la tarea. Enviar, publicar, gastar y otras acciones con consecuencias tienen requisitos de aprobación separados. Para los textos públicos bajo mi nombre, reviso la pieza terminada.
Aquí hay dos capas. Las instrucciones escritas le dicen a la asistente cómo comportarse. Los permisos de las herramientas y las comprobaciones específicas pueden hacer cumplir parte de ese comportamiento. Una regla en un documento no es, por sí sola, una barrera técnica.
Necesito ambas cosas y necesito saber de cuál dependo. Si la asistente tiene más acceso del que requiere la tarea, un párrafo que le pida cuidado no elimina ese acceso.
Dónde sigo participando
Leer el diagrama como texto
Prepara el trabajo
Investiga, redacta y haz cambios reversibles dentro de la tarea.
Tráeme la pieza
Muestra el trabajo terminado y la acción para la que está listo.
Revisa el permiso
Publicar, enviar o gastar requiere la aprobación correspondiente.
Haz que «terminado» apunte a algo
Cuando estaba publicando la guía Practical AI Safety, pedí que se subiera a la rama principal. Después pedí que se desplegara hasta quedar publicada por completo.
Eran pedidos separados por una razón. Un archivo puede estar guardado en mi computadora. El código puede estar en GitHub. Ninguna de esas cosas le dice al lector dónde abrir la guía.
Quería la página que la gente pudiera usar. Eso significaba seguir el trabajo más allá del repositorio y comprobar la dirección pública.
Las comprobaciones incluyeron comparar los archivos publicados con la versión guardada en el repositorio y revisar la página pública en un navegador. Esas pruebas respaldaban una conclusión concreta: la guía aprobada estaba disponible y las interacciones revisadas funcionaban.
No demostraban que los buscadores la hubieran indexado, que alguien la hubiera leído ni que me hubiera traído un cliente.
Ese es el informe de cierre que quiero. Dime qué cambió, muéstrame dónde está y termina la afirmación donde terminan las pruebas.
Puedes revisar el resultado público en mi guía Practical AI Safety y en su repositorio de GitHub. Son materiales públicos de enseñanza. No incluyen mis archivos privados de trabajo.
¿Qué demuestra «terminado»?
Leer el diagrama como texto
Guardado localmente
Los archivos existen en la computadora. Los lectores todavía no pueden usarlos.
Subido a GitHub
El código llegó al repositorio. La página pública todavía necesita una revisión.
Revisado en público
Abre la página publicada y prueba el recorrido previsto para el lector.
Evita que las instrucciones nuevas dejen copias viejas atrás
Las instrucciones pueden extenderse. La misma regla puede aparecer en un archivo del proyecto, en la configuración de una herramienta y en una rutina que se ejecuta después. Actualizar el original no actualiza necesariamente todos los lugares que dependen de él.
Mi sistema incluye un proceso para seguir esas dependencias. Cada cambio de una regla permanente recibe un identificador. Hay que dar cuenta de los lugares registrados que dependen de ella, con pruebas que muestren si cada uno se actualizó, ya recibe la regla o todavía tiene una falta.
Una comprobación valida esa estructura declarada y las pruebas requeridas. No lee cada frase del sistema para decidir si todos los textos coinciden. Una configuración activa fuera del repositorio también necesita su propia revisión.
Ese límite pertenece a la descripción. Si lo omito, una comprobación útil se convierte en una promesa mucho mayor de la que el código puede cumplir.
Trata una lección como candidata antes de volverla regla
También tengo un proceso escrito para aprender de los errores. Una observación empieza como candidata. Convertirla en un comportamiento permanente requiere más confirmación, mi confirmación y comprobaciones de que el cambio llegó a los lugares que dependen de él.
Esto importa porque una asistente puede sacar una lección demasiado amplia de un solo intercambio. Una preferencia para un texto no se aplica automáticamente a todo lo que escribiré en mi vida.
Recordar más solo ayuda si lo recordado conserva su contexto. Quiero poder seguir una regla hasta las pruebas y la decisión que la justificaron, y después cambiarla o retirarla cuando esa base ya no se sostenga.
Qué demuestra este caso y qué no
Este es un caso práctico de un sistema que uso y sigo revisando. No he hecho una comparación controlada que demuestre cuánto reduce los errores, ahorra tiempo o mejora los resultados del negocio.
La publicación ofrece un ejemplo de trabajo y verificación que se puede revisar. La corrección de marca ofrece un ejemplo de un fallo que todavía me necesitó. Ninguna de las dos cosas es una tasa medida de fiabilidad de toda la asistente.
También hay costos. Las instrucciones necesitan mantenimiento. Las fuentes pueden quedar viejas. Demasiados pasos de aprobación pueden interrumpir trabajo útil. Una comprobación automática que pasa puede invitar a tener más confianza de la que merece su alcance limitado.
Para probar el diseño más en serio, compararía las mismas tareas definidas con y sin los controles añadidos. Registraría las instrucciones incumplidas, las afirmaciones de cierre sin respaldo, las interrupciones innecesarias y el esfuerzo humano para detectar y corregir los errores. Hasta que exista esa comparación, no debería ponerle un porcentaje al beneficio.
Tampoco puedo sostener que nadie más haya construido algo parecido. Lo que sí puedo mostrar es cómo conecté la revisión de fuentes, los límites de permiso, el seguimiento de cambios y las pruebas de cierre alrededor de mi propio trabajo, incluido el punto donde falló esa conexión.
Construye una versión que puedas revisar
Si estás construyendo tu propio asistente personal de IA, empieza con una tarea real cuyo resultado sepas comprobar. Dale la fuente pertinente, aclara qué puede hacer y decide qué demostraría que la tarea está terminada.
Pruébalo cuando falte información o las instrucciones se contradigan. Observa si te muestra la falta o escribe como si no existiera. Ese comportamiento te dirá más que una presentación pulida sobre todo lo que puede hacer.
Publiqué gratis un paquete inicial para un asistente personal de IA con materiales reutilizables y ejemplos ficticios. Los ejemplos son para practicar. Pasar sus comprobaciones no certifica que tu asistente sea seguro.
Si quieres ayuda para construirlo alrededor de tu trabajo, mi acompañamiento para un asistente personal de IA es el lugar para empezar esa conversación.
Todavía pienso en aquellos archivos separados del cuestionario cuando añado otra instrucción o herramienta. ¿Esto ayuda a la asistente a terminar el trabajo real o me he dado otra cosa que administrar?
Y todavía reviso el naranja.