Artículo
No todos estamos viendo la misma IA: la lectura de Karpathy y una prueba para tu negocio
Una conversación que necesita contexto
Dos personas pueden probar una herramienta de IA y llegar a conclusiones opuestas porque le piden trabajos diferentes y evalúan resultados distintos. Para decidir su uso en un negocio conviene definir una tarea, un criterio de calidad y un límite de costo. Este análisis propone cómo hacerlo sin convertir una demostración en una promesa.
Imagina una reunión comercial. Una persona cuenta que obtuvo un buen resumen; otra dice que la herramienta inventó condiciones de una oferta. Ambas experiencias pueden ser reales. Ninguna, por sí sola, responde si conviene incorporar IA al proceso de preparar propuestas. Falta conocer los materiales entregados, la revisión necesaria y las consecuencias de equivocarse.
Una discusión útil empieza con preguntas concretas: ¿qué trabajo se intentó resolver?, ¿con qué información?, ¿quién decidió que la respuesta servía? Ese cambio permite salir de opiniones generales y construir una decisión que el equipo pueda revisar.
Qué aporta la lectura de Karpathy
Karpathy plantea que la experiencia con los modelos cambia según el acceso, el ámbito de trabajo y la escala del problema. Describe capacidades desiguales entre tareas. Es una interpretación del autor; sus estimaciones de adopción no se usan aquí como estadísticas ni como prueba de resultados empresariales.
La pregunta editorial que surge de esa lectura es práctica: ¿estamos juzgando una tecnología con una prueba que representa nuestro trabajo? Si el equipo solo le pide redactar mensajes, la experiencia observada cubre esa tarea. Para saber si ayuda a preparar una propuesta con restricciones reales, habrá que evaluarla en ese proceso específico.
La propuesta de este artículo es tratar cada configuración como una herramienta distinta a efectos de evaluación. Anota el producto, la versión visible, las funciones habilitadas y la información disponible. Si cambia alguno de esos elementos, conserva el resultado anterior como referencia y decide qué parte de la prueba necesita repetirse.
Tres formas de pedir trabajo
Esta tabla es un marco editorial de aplicación. Los niveles describen encargos posibles, no una clasificación de personas ni garantías de capacidad. Un sistema puede funcionar en el primer nivel y fallar en el siguiente; también puede requerir tanta revisión que pierda utilidad para una tarea aparentemente sencilla.
Conviene escoger el nivel que corresponde al problema actual. Preparar un buen borrador puede ser suficiente cuando una persona debe negociar cada condición. Un flujo más amplio solo merece evaluarse si resuelve una necesidad concreta y permite localizar el origen de los errores. La complejidad añadida también necesita justificación.
| Encargo | Ejemplo hipotético | Qué comprobar |
|---|---|---|
| Respuesta puntual | Ordenar dudas de una solicitud. | Fidelidad al texto y preguntas pendientes. |
| Entregable revisable | Preparar una propuesta con catálogo. | Precios, condiciones y trazabilidad. |
| Proceso con etapas | Preparar, contrastar y corregir el borrador. | Estado de cada etapa, costo y aprobación humana. |
Un mapa para elegir la prueba
La figura propone dos preguntas propias para seleccionar un experimento: ¿podemos comprobar el resultado?, ¿qué ocurre si es incorrecto? Cruzarlas ayuda a elegir dónde empezar. No representa porcentajes de usuarios, rendimiento de modelos ni una curva de progreso. Su función es hacer visible el riesgo operativo que el equipo acepta.
Una propuesta comercial puede contener partes fáciles de comprobar, como referencias a un catálogo, y partes que exigen juicio, como una concesión contractual. Separarlas mejora el diseño del ensayo. El borrador puede incluir la evidencia de cada precio y señalar condiciones pendientes; la decisión de ofrecerlas necesita una persona responsable.
Cuando no existe un criterio claro para aceptar la salida, define primero cómo la revisarás. Si el criterio depende de información que falta, permite que la respuesta correcta sea pedirla. Obligar al sistema a completar todos los campos favorece una apariencia de certeza que el negocio no necesita.
- Comprobable y consecuencias acotadas: candidato para un primer ensayo.
- Comprobable y consecuencias importantes: revisión antes de usar la salida.
- Difícil de comprobar y consecuencias acotadas: exploración con criterios por construir.
- Difícil de comprobar y consecuencias importantes: no automatizar la decisión.
La posición depende de la tarea y de los controles disponibles. El mapa no cuantifica capacidad ni adopción.
El caso: preparar una propuesta comercial
Ejemplo hipotético, creado para aprender: una pequeña consultora recibe solicitudes de clientes y prepara propuestas a partir de un catálogo de servicios. Quiere evaluar si una herramienta de IA ayuda a producir borradores revisables. No hay resultados medidos ni datos de Álvaro asociados a este ejemplo.
El encargo tiene límites: identificar la necesidad expresada, seleccionar servicios permitidos, explicar supuestos y señalar información faltante. El borrador no puede inventar tarifas, confirmar fechas sin disponibilidad ni enviar mensajes. Una persona conserva la aprobación y el envío. La prueba utiliza materiales ficticios o anonimizados con permiso para ese uso.
Antes de comenzar, prepara un catálogo pequeño, una plantilla y una rúbrica. Incluye solicitudes claras, solicitudes incompletas y un caso en que el cliente pide algo fuera del catálogo. Añade una contradicción deliberada entre dos documentos para comprobar si la herramienta la detecta o elige una condición sin advertirlo.
Cómo construir una comparación justa
Establece una línea base con el proceso habitual. Conserva la propuesta inicial, las correcciones y la versión aceptada. Registra el tiempo de preparación y el de revisión por separado. Una tarea con un resultado rápido pero defectuoso todavía no ha llegado a la entrega que el equipo necesita.
Usa un conjunto pequeño de solicitudes equivalentes y fija las instrucciones antes de observar los resultados. Divide los casos en dos grupos comparables: en uno comienza el proceso habitual y en otro comienza la herramienta. Alternar el orden puede ayudar a detectar si la práctica está influyendo en los tiempos. Un ensayo pequeño conserva incertidumbre; no permite generalizar a todos los clientes.
Entrega a la persona evaluadora la rúbrica y los borradores con etiquetas neutrales cuando sea posible. Pídele que compruebe exactitud, cobertura, claridad y condiciones no autorizadas. Guarda sus razones, además de la puntuación. Si los casos son diferentes, registra esa diferencia para evitar atribuir al sistema una dificultad que proviene de la solicitud.
Qué medir antes de hablar de ahorro
Define la aceptación antes de ejecutar: toda tarifa debe provenir del catálogo, ninguna condición puede presentarse como aprobada sin evidencia y toda ambigüedad material debe quedar visible. Después evalúa si la propuesta responde al pedido y si alguien puede usarla para continuar la conversación. Una redacción elegante no compensa un compromiso incorrecto.
Registra el tiempo completo hasta la aceptación: preparación de materiales, interacción, revisión y correcciones. Para el costo, separa consumo de la herramienta, suscripción atribuible y trabajo humano. Si no puedes asignar un costo con evidencia, conserva ese dato como no disponible. No conviertas una reducción de minutos en ingresos supuestos.
Cuenta también el retrabajo: campos corregidos, rondas de revisión y errores repetidos. Una mejora de tiempo con más errores críticos exige revisar la decisión. Un resultado correcto que tarda más puede tener utilidad en otro contexto, pero esa utilidad debe describirse y evaluarse. El informe final debe permitir reconstruir por qué se aceptó cada salida.
Compara casos pareados y muestra diferencias, no solo promedios. Una tarea excepcionalmente fácil puede ocultar un fallo importante. Indica cuántas propuestas cumplieron todos los criterios y cuáles necesitaron intervención. Esas observaciones sostienen una decisión limitada al ensayo; todavía no acreditan productividad sostenida.
Cuándo detener, corregir o ampliar
Detén el caso si aparecen tarifas inventadas, condiciones no autorizadas, datos sensibles fuera del alcance o intentos de envío. Conserva la evidencia y revisa la causa antes de continuar. Fija también un máximo de tiempo y consumo por solicitud: una sucesión de intentos sin convergencia debe terminar con una revisión humana.
Si el problema es una instrucción ambigua, prepara una corrección y evalúala en casos nuevos. Si falta información del cliente, mejora la pregunta de aclaración. Si el error nace de materiales contradictorios, corrige su autoridad y vigencia. Cambiar de modelo puede ser una hipótesis, pero no sustituye el diagnóstico del proceso.
Amplía solo cuando el equipo acepta la calidad y puede explicar los límites observados. La siguiente etapa podría añadir variedad de solicitudes manteniendo aprobación humana, presupuesto y registro de fallos. Automatizar el envío sería otra decisión, con permisos y comprobaciones propios. El éxito de un borrador no autoriza esa transición.
Una decisión que puedes defender
Al terminar, escribe una conclusión concreta: qué tareas probaste, con qué configuración, qué se aceptó y qué condiciones impiden ampliar. Incluye lo que no se pudo medir. Si los resultados son mixtos, conserva esa diferencia: quizá la herramienta sirve para estructurar información y todavía requiere mucha ayuda para formular condiciones.
La utilidad de este ejercicio consiste en hacer verificable la conversación. El equipo obtiene ejemplos revisados, un registro de costo y una lista de fallos que puede corregir. La incertidumbre sigue presente, pero ya tiene nombre y consecuencias. Esa es una base más firme para decidir una inversión, una nueva prueba o una pausa.
Para continuar, elige una tarea acotada de tu negocio y escribe sus criterios antes de probar una herramienta. En la Comunidad puedes llevar la pregunta, el esquema de evaluación y las dudas del ensayo para aprender junto a otras personas. Comparte ejemplos sin información privada y distingue siempre una hipótesis de un resultado medido.
Fuente y límites de esta lectura
Publicación original de Andrej Karpathy.
La captura muestra una última edición el 11 de octubre de 2026, a las 16:12, sin zona horaria acreditada. La fecha original de publicación no está acreditada.
Este artículo es un análisis editorial. No verifica cifras de adopción ni resultados técnicos mencionados por el autor. El caso comercial y el mapa son originales e hipotéticos.