5 errores que las áreas financieras cometen al usar Claude, y lo que les cuestan cada mes

El patrón se repite con una consistencia que ya dejó de sorprenderme: una empresa compra licencias de Claude, alguien del equipo las usa para tareas triviales (redactar un correo, revisar un Excel simple) y, a los pocos meses, concluye que la inteligencia artificial está sobrevalorada. En realidad, lo que está pasando es que se está dejando sobre la mesa exactamente la parte que sí genera retorno.

Estos son los cinco errores más comunes que veo en áreas financieras que ya pagan la herramienta pero no ven el resultado, y lo que cuesta cada uno en tiempo y en decisiones que se toman más lento de lo necesario.

Error 1: trabajar siempre en la ventana equivocada

Claude no es una sola superficie de trabajo, son tres, y usar siempre la misma para todo es lo que más desperdicia límite de uso sin generar resultado.

El chat sirve para resolver una duda puntual o pulir un texto. Cuando la tarea implica veinte archivos, varias entidades o un entregable con formato, el chat deja al usuario haciendo manualmente la subida y bajada de archivos, uno por uno.

Cowork es el paso natural para procesos de varios archivos con un entregable final: un Excel, una presentación, un documento. Y Claude Code es la opción para procesos predecibles y repetibles a volumen, porque corre igual sobre 800 documentos que sobre 8. Vale la pena aclarar algo que se malinterpreta seguido: Code no es solo para programadores. Trabaja sobre una carpeta real, abre PDFs y hojas de cálculo, y guarda todo de vuelta como archivos normales, en lenguaje natural, igual que el chat.

He visto equipos financieros gastar su límite de uso completo en el chat, tratando de resolver ahí tareas que debían ir en Cowork o en Code. Casi siempre, lo que faltaba no era la herramienta correcta, sino un "champion" interno que liderara el salto de lo básico a lo que de verdad transforma el proceso.

Ese champion no necesita ser el puesto más senior del área. En la práctica, suele ser la persona con más curiosidad natural por la herramienta, no la de mayor rango. Su trabajo no es aprender a programar, es aprender a distinguir, para cada tarea nueva que llega al equipo, cuál de las tres ventanas le corresponde, y explicárselo al resto del equipo con ejemplos concretos de su propia operación. Sin ese rol, cada persona del equipo sigue resolviendo todo en la ventana que ya conoce, casi siempre el chat, aunque no sea la correcta para el volumen de la tarea.

Error 2: dejar la información lejos de la herramienta

Existen cientos de archivos (ventas, estados financieros, declaraciones, facturas) que nunca se aprovechan porque viven lejos de la herramienta, y alguien tiene que bajarlos, procesarlos y volver a subirlos a mano cada vez.

Los conectores (Drive, Microsoft 365) resuelven esto. Se activan desde el menú de la caja de mensaje o en Personalizar, Conectores. Requieren permiso de perfil de administrador, y conviene revisar con cuidado la configuración de permisos cuando se trata de información confidencial.

Hay un beneficio menos obvio que vale la pena señalar: cuando la fuente vive en la nube, una tarea programada puede correr sin que la computadora de nadie esté encendida. Con archivos locales, en cambio, la aplicación de escritorio tiene que estar abierta para que el proceso avance.

La regla de diseño que sigo con mis clientes: una carpeta dedicada, con permiso de escritura solo para quien alimenta la información y de lectura para todo lo demás. Nunca se conecta la unidad completa.

Error 3: pedir respuestas cuando deberías pedir entregables

Un prompt de tres líneas produce, casi siempre, una salida de tres líneas de valor. Lo que separa el uso amateur del profesional es una estructura de seis partes:

• Rol y contexto: la empresa, las entidades, la moneda, el sistema con el que se trabaja.
• Insumo exacto: el archivo, la carpeta, el periodo específico. Nunca "los financieros", siempre el archivo y el periodo exactos.
• Producto de salida: qué archivo, qué hojas, qué formato final se espera.
• Restricciones: qué no hacer, qué no asumir, qué se debe reportar como excepción en lugar de resolverse solo.
• Punto de verificación: "muéstrame qué identificaste antes de escribir nada, y espera mi confirmación".
• Regla de honestidad: "si un dato no se puede calcular, dilo, en lugar de estimarlo".

Las últimas dos son las que de verdad separan el uso amateur del profesional. Un modelo que rellena un hueco con una estimación plausible es un riesgo inaceptable cuando ese número va a salir hacia un banco, un inversionista, un socio o un proveedor. Pedir explícitamente que se reporte como excepción, en lugar de estimar, es la diferencia entre un proceso confiable y uno que algún día te va a costar una llamada incómoda.

Aplicado a una conciliación bancaria mensual, las seis partes se ven así: rol y contexto ("eres el analista de tesorería de una empresa manufacturera con cuentas en tres bancos"); insumo exacto ("los estados de cuenta de julio 2026 de los tres bancos en 00_entrada, y el auxiliar contable del mismo periodo"); producto de salida ("un Excel de conciliación con una hoja por banco y un resumen de partidas en tránsito"); restricciones ("no concilies partidas con diferencia mayor a cierto monto sin marcarlas para revisión manual"); punto de verificación ("muéstrame las partidas que no cuadran antes de dar la conciliación por cerrada"); y regla de honestidad ("si un movimiento no tiene soporte identificable, repórtalo como pendiente, no lo asumas como conciliado"). La diferencia entre pedir esto y pedir simplemente "concilia mis bancos" es la diferencia entre un archivo que se puede auditar y uno que hay que revisar línea por línea de todos modos.

Error 4: no usar Projects, o usarlos a medias

Un proyecto agrupa el trabajo relacionado (los reportes mensuales, el procesamiento de facturas, un cliente o un caso específico) en un espacio con instrucciones propias, contexto (la carpeta local, un proyecto vinculado, URLs de referencia), tareas programadas propias y memoria acotada, de modo que lo aprendido en un proyecto no contamina otro.

Hay dos limitaciones prácticas que conviene conocer antes de diseñar tu flujo alrededor de esta función. Los proyectos son de escritorio y se guardan localmente sin sincronización en la nube por ahora, y en planes de equipo no se comparten entre miembros. Si varias personas operan el mismo proceso, la fuente de verdad tiene que ser los archivos en la nube, nunca el proyecto en sí.

Con mis clientes de Scaling CFO®, estructuro un proyecto por entidad o por proceso, precisamente para evitar que el contexto se mezcle entre ellos. Todo proyecto necesita instrucciones claras, aclaraciones de contexto y documentos base. No basta con ponerle un nombre y dejarlo con una carpeta vacía.

El error más frecuente que veo con Projects no es no usarlos, es crearlos y dejarlos con instrucciones genéricas o vacías, esperando que el contexto se construya solo con el tiempo. Un proyecto sin instrucciones explícitas sobre qué hacer y qué no hacer se comporta, en la práctica, casi igual que un chat suelto: cada conversación empieza de cero en cuanto al criterio, aunque técnicamente viva dentro del mismo proyecto. El valor real de un Project aparece cuando alguien invierte la primera hora en escribir, con detalle, las reglas de negocio, los criterios de clasificación y las excepciones conocidas. Esa hora inicial es la que ahorra las siguientes veinte.

Error 5: corregir la salida en lugar de corregir el criterio

Este es el error más caro de los cinco, y también el más invisible. Si el Excel se corrige a mano cada mes, el mismo error vuelve el mes siguiente, porque nadie corrigió la causa, solo el síntoma.

Una Skill es una carpeta con un archivo de instrucciones en formato MD que Claude reconoce y aplica cuando la tarea corresponde. Es el mecanismo por el cual el criterio de un contador o de un contralor deja de vivir solo en su cabeza, y pasa a vivir en un procedimiento que cualquiera puede ejecutar igual.

La regla de diseño es la misma que en la Parte 1 de esta serie: tres habilidades chicas rinden más que una gigante que intenta consolidar, analizar y graficar al mismo tiempo, porque pierde contexto entre tareas distintas. Hay que separarlas por producto de salida, y priorizar los procesos que no cambian de un mes a otro, que son los que más se benefician de hacerse exactamente igual cada vez.

Diseñé para un cliente una Skill puntual, dedicada solo a clasificar un tipo de gasto que su equipo llevaba meses reclasificando a mano cada cierre: un renglón de fletes que el sistema contable original cargaba a gasto general y que, por la naturaleza del negocio, debía ir a costo de ventas. Antes de la Skill, alguien del equipo revisaba manualmente cada póliza del mes para hacer esa reclasificación, un ejercicio de aproximadamente tres horas que se repetía sin falta cada cierre. Con la regla escrita una sola vez en la Skill, esa reclasificación ocurre sola cada vez que se corre el proceso, y las tres horas se liberaron para siempre, no solo una vez.

El patrón detrás de los cinco errores, y la parte incómoda que nadie dice

Ninguno de estos cinco es, en el fondo, un error de la herramienta. Son errores de arquitectura de trabajo. Y hay una parte incómoda que vale la pena decir con todas sus letras: la inteligencia artificial acelera lo que ya está definido, y también acelera el error en un proceso que nunca tuvo un criterio claro.

El proyecto guarda el contexto, la habilidad guarda el criterio, la carpeta guarda las instrucciones y la información crítica, y Code lo estructura a volumen. Quien solo abre el chat obtiene respuestas buenas. Quien arma las cuatro piezas obtiene un proceso que corre igual el mes que la persona que lo diseñó se va de vacaciones.

He acompañado esta transición en áreas financieras que iban desde un Excel heroico hasta un ERP recién implementado, y el patrón se repite sin excepción: el primer mes se gana ordenando, no automatizando.

Vale la pena decirlo de otra forma, porque es la conclusión que más me ha costado transmitir: ninguno de estos cinco errores se corrige comprando más licencias, ni cambiando de modelo de IA, ni esperando a que la siguiente versión de la herramienta sea más inteligente. Se corrigen con las mismas prácticas de disciplina y estructura que ya existían antes de que la inteligencia artificial llegara a la conversación: procesos documentados, criterios escritos, información ordenada y responsables claros. La inteligencia artificial no sustituye esa disciplina, la premia cuando existe y la castiga, de forma visible y rápida, cuando no existe.

Si quieres identificar en cuál de estos cinco errores está cayendo tu área financiera, y con qué corregirlo primero, lo revisamos en un diagnóstico de madurez de IA de Flint Consulting®.

Fuentes. Centro de ayuda de Anthropic, documentación sobre Claude Cowork, Claude Code, Projects, Skills y conectores, consultada en agosto de 2026. Gartner, noviembre de 2025: 59% de las funciones financieras reportó uso de IA en 2025, y solo 36% de los CFOs se siente capaz de dirigir su impacto. McKinsey, encuesta a 102 CFOs: 44% usó IA generativa en cinco o más casos de uso, y 65% aumentará su inversión.

¿Quieres saber más?
connect@flintconsulting.mx  |  +52 81 1351 8242  |  flintconsulting.mx