La respuesta corta
Convertir el criterio del dueño en un agente de IA exige registrar cómo toma decisiones, no solo los pasos que ejecuta. El sistema necesita casos reales, excepciones, límites de autonomía, evidencia obligatoria y puntos de aprobación humana. El objetivo no es copiar la mente del dueño. Es lograr que el trabajo repetible avance sin que el negocio pierda juicio ni control.
El problema no es que el proceso esté en tu cabeza
Muchos dueños pueden explicar su trabajo mientras lo hacen, pero no antes. Revisan una propuesta y detectan que algo no encaja. Leen un mensaje de un prospecto y saben si conviene insistir, esperar o retirarse. Escuchan cinco minutos de una llamada y distinguen una objeción real de una excusa. La decisión parece rápida porque años de experiencia quedaron comprimidos en una reacción.
Eso se conoce como conocimiento tácito. California Management Review lo describe como patrones de razonamiento, reglas informales, atención al contexto y habilidades de interpretación que rara vez aparecen en manuales o tableros. No es conocimiento mágico. Es conocimiento que todavía no fue expresado de una forma que otra persona o un sistema pueda usar.
El error aparece cuando el dueño intenta delegarlo con una lista superficial: revisa el lead, responde bien, usa mi tono, toma una buena decisión. El agente recibe verbos, pero no recibe criterio. Entonces produce algo aceptable en apariencia y el dueño termina corrigiendo cada salida. Delegó la tarea, pero conservó todo el trabajo mental. Peor todavía, añadió una nueva obligación: vigilar una herramienta que no entiende por qué una decisión es correcta.
Qué significa convertir criterio en un sistema ejecutable
El criterio del dueño es la forma consistente de elegir una acción cuando la respuesta no viene escrita en un procedimiento. Incluye qué señales considera importantes, cuáles descarta, qué riesgo no acepta, cuándo pide más información y qué excepción cambia la regla.
Convertirlo en un sistema ejecutable significa registrar esas decisiones con suficiente contexto para que puedan repetirse y revisarse. No basta con escribir qué hacer. También hay que guardar por qué se eligió esa acción, qué evidencia la respalda y bajo qué condición el agente debe detenerse.
La diferencia es concreta. Un procedimiento dice: si el prospecto no responde, envía seguimiento. El criterio añade: no envíes otro mensaje si ya rechazó la oferta, si pidió una fecha específica o si el último contacto requiere una respuesta humana. También define qué cuenta como rechazo, cómo se reconoce una fecha y qué dato debe quedar en el CRM. Ahí empieza el control real.
Empieza por una decisión que se repite, no por todo tu negocio
Anthropic distingue entre flujos de trabajo, donde el camino está definido por código, y agentes, donde un modelo decide cómo avanzar usando herramientas. Su recomendación es empezar con la solución más simple y añadir complejidad solo cuando sea necesaria. Ese consejo importa porque muchos proyectos fallan antes de comenzar: intentan convertir ventas, contenido, soporte y administración en un solo agente.
Elige una decisión frecuente que hoy te interrumpe. Puede ser clasificar solicitudes, preparar el primer borrador de una respuesta, revisar si un registro está completo o decidir qué casos necesitan tu atención. Debe tener un inicio reconocible, información disponible y un resultado que puedas evaluar.
Luego separa lo fijo de lo que exige juicio. Recibir un formulario, validar campos y guardar un registro son pasos fijos. Decidir si el caso merece prioridad puede requerir interpretación. Si mezclas ambos tipos de trabajo, el agente improvisará donde debería obedecer y se quedará corto donde sí necesitaba contexto.
Esta es una decisión distinta a escoger una herramienta. Antes de comparar opciones, define la tarea, el riesgo y la salida manual. Una herramienta no puede resolver la falta de alcance ni decidir cuánto control debe conservar el dueño.
Extrae el criterio con casos reales y contrastes
Pedirle al dueño que escriba todas sus reglas suele producir frases demasiado generales. Funciona mejor revisar decisiones reales. Toma entre diez y veinte casos recientes del mismo proceso y pregunta qué ocurrió, qué señales observaste, qué elegiste y qué habría cambiado tu decisión.
Los contrastes revelan más que una explicación aislada. Busca dos casos parecidos que terminaron de forma distinta. Tal vez ambos prospectos pidieron tiempo, pero uno dio una fecha y el otro evitó comprometerse. Tal vez dos propuestas tenían el mismo presupuesto, pero solo una dependía de información que el negocio no podía verificar. La diferencia entre esos casos contiene una regla útil.
Registra también los casos donde dudaste. Si el dueño necesitó hacer una pregunta adicional, el agente probablemente necesitará la misma salida. Un sistema serio no oculta la incertidumbre. La convierte en una acción: pedir un dato, escalar el caso o detener la ejecución.
California Management Review advierte que codificar conocimiento tácito sin contexto puede aplanar su riqueza. Por eso los ejemplos deben conservar situación, señales y consecuencia. Una lista de respuestas correctas enseña poco. Una pareja de casos, uno aceptado y otro rechazado, muestra dónde vive la decisión.
Define cuatro límites antes de darle acceso
Primero define qué puede ejecutar sin pedir permiso. Deben ser acciones reversibles, de bajo riesgo y fáciles de verificar. Ordenar información o preparar un borrador suele ser más seguro que enviar, borrar o cambiar el estado final de una venta.
Segundo, define qué necesita aprobación. La aprobación no debe aparecer en cada paso, porque convertiría al agente en otra bandeja de tareas. Debe concentrarse en decisiones sensibles: mensajes externos, compromisos de dinero, cambios que afecten a un cliente o casos donde falta evidencia.
Tercero, exige un rastro de evidencia. Para cada acción importante, el sistema debe poder mostrar qué recibió, qué regla aplicó, qué resultado produjo y si una persona aprobó. IBM señala que los agentes operan con metas y reglas definidas por humanos. Sin registro, esas reglas existen solo como intención y el dueño no puede saber si realmente se respetaron.
Cuarto, conserva una salida manual. Si falla una integración, cambia una herramienta o aparece un caso nuevo, el proceso debe poder volver a una persona sin perder información. La continuidad depende de probar sustituciones y mantener el control fuera del modelo.
Prueba decisiones, no demostraciones bonitas
Una demostración puede acertar tres veces y seguir siendo peligrosa. La prueba útil reúne casos normales, excepciones y situaciones incompletas. Cada resultado se compara contra una decisión esperada: ejecutar, pedir aprobación, solicitar información o detenerse.
No midas solo si la respuesta suena bien. Mide si usó la fuente correcta, respetó el límite, guardó evidencia y eligió la acción permitida. Un texto elegante con una decisión equivocada sigue siendo un fallo.
Cuando el agente falla, no corrijas únicamente la respuesta final. Identifica qué faltaba: una regla, un ejemplo, una excepción, una fuente o una condición de parada. Ese ajuste convierte un error en conocimiento que el sistema puede reutilizar. Si solo editas el texto cada vez, vuelves al punto de partida y el dueño continúa haciendo el trabajo detrás de la herramienta.
Cuándo el agente ya está listo para trabajar contigo
Está listo para una primera operación acotada cuando el proceso tiene dueño, entrada, resultado esperado y una forma clara de detenerse. También debe existir una fuente de verdad. Si la información vive repartida entre mensajes, memoria y hojas sin actualizar, el agente no arreglará esa contradicción. La ejecutará más rápido.
La primera versión no necesita reemplazar el proceso completo. Puede preparar decisiones y dejar la aprobación final al dueño. Con suficiente evidencia, algunas acciones de bajo riesgo pueden pasar a ejecución directa. Otras deben quedarse bajo revisión de forma permanente.
Ese reparto no es una falla de autonomía. Es diseño. El dueño deja de mover cada pieza y conserva las decisiones que tienen consecuencias. Si necesitas definir ese alcance antes de instalar nada, la conversación debe empezar por una sola decisión repetida, no por una lista de herramientas.
Para quién NO es
No es para quien todavía no tiene un proceso real y espera que la IA invente el negocio. Tampoco sirve si cada caso es completamente distinto, no existe información verificable o nadie acepta hacerse responsable de la decisión final.
No aplica a quien busca autonomía total desde el primer día, quiere conectar todas sus herramientas de una vez o no puede ofrecer ejemplos reales del trabajo. Si el volumen es bajo y la decisión ocurre una vez al mes, documentarla puede ser suficiente. Construir un agente añadiría más mantenimiento que valor.
Limitaciones
Extraer criterio no garantiza que todas las decisiones puedan automatizarse. Parte del conocimiento depende de relaciones, información privada, cambios del mercado o responsabilidad legal. Esos límites deben quedar fuera del alcance o bajo aprobación humana.
Las fuentes citadas explican patrones generales sobre agentes y conocimiento tácito. No prueban un resultado comercial para tu negocio ni sustituyen una prueba con tus propios casos. La calidad final depende de la evidencia disponible, la estabilidad del proceso y la disciplina para revisar errores sin convertir cada excepción en una regla nueva.
El objetivo tampoco es documentar toda la experiencia del dueño. Eso sería lento y probablemente inútil. Basta con capturar el criterio necesario para una tarea delimitada, probarlo y decidir si merece ampliarse. Un proceso. Una fuente de verdad. Una acción principal. Ahí comienza.