Documentar reglas empresariales para apps de IA en lenguaje claro

Por qué las reglas poco claras crean apps poco fiables

Las reglas empresariales indican a una app qué hacer en situaciones reales. Responden preguntas como quién puede aprobar una solicitud, cómo se calcula un total y qué sucede cuando un caso se sale del patrón habitual.

Si esas reglas son vagas, la app igual tendrá que escoger un camino. Solo que quizá no escoja el que tú esperabas.

Toma una regla como "los gastos grandes necesitan aprobación del manager". Una persona puede pensar que suena clara. Un constructor no. ¿Qué cuenta como grande: $500, $5,000 o cualquier cosa por encima del presupuesto del equipo? ¿Qué manager: el manager directo, el jefe de departamento o finanzas? Si nadie responde en dos días, ¿la solicitud espera, caduca o pasa a otra persona?

Por eso las reglas vagas conducen a apps poco fiables. El constructor solo puede ser tan consistente como las instrucciones que recibe. Cuando el texto deja sitio para conjeturas, la app puede comportarse de una manera hoy y de otra mañana cuando aparezca un caso ligeramente distinto.

Los mayores problemas suelen aparecer en unas pocas áreas:

• cálculos con detalles faltantes, como redondeo, impuestos, descuentos o rangos de fecha
• excepciones que todos asumen pero nadie escribe
• pasos de aprobación sin un propietario claro, sin orden o sin plan B

Un ejemplo simple muestra el problema. Un fundador crea una app interna de gastos en Koder.ai y escribe: "Reembolsar gastos de viaje a menos que parezcan inusuales." Eso suena razonable, pero la app no tiene una forma fiable de juzgar qué es inusual. A un empleado se le aprueba un taxi, a otro similar se le marca, y nadie sabe por qué.

El comportamiento fiable empieza con reglas que se puedan seguir de la misma manera cada vez. Palabras como "grande", "urgente" y "caso especial" deben reemplazarse por límites, condiciones y acciones exactas. Si dos personas diferentes aplicarían la regla de la misma forma, la app tiene mucha más probabilidad de hacer lo mismo.

Cómo es una regla empresarial clara

Una regla clara cubre una decisión o una acción, no un proceso entero. Esto importa más de lo que la mayoría de equipos espera. Cuando una regla intenta cubrir aprobación, precios, excepciones y notificaciones a la vez, el constructor tiene que adivinar qué parte importa más.

Una buena regla se puede leer en voz alta con facilidad. Alguien fuera de tu equipo debería entenderla sin necesidad de tu jerga interna. Reemplaza términos como "fast-track", "caso estándar" o "firma del manager" por lenguaje claro que diga exactamente lo que pasa.

La mayoría de las reglas claras responden cuatro preguntas básicas:

• ¿Quién toma la decisión o realiza la acción?
• ¿Cuándo se aplica la regla?
• ¿Qué cambia en la app?
• ¿Qué sucede después?

Esa estructura mantiene la regla atada a un comportamiento real. En lugar de escribir "Los pedidos grandes necesitan revisión", escribe "Si un pedido supera los $5,000, el sales manager debe aprobarlo antes de enviarlo a fulfillment." Una frase, una decisión, un resultado.

También ayuda mantener las reglas relacionadas separadas. La regla de aprobación debe sostenerse por sí misma. La regla de enviar un correo debe estar separada. La regla de bloquear un envío también. Eso hace que cada regla sea más fácil de probar, actualizar y corregir.

La diferencia se ve con claridad:

"Los clientes premium reciben manejo prioritario" es vago.

"Si el cliente tiene un plan premium, la solicitud de soporte se marca como Alta Prioridad cuando se crea el ticket" es claro.

La segunda versión nombra el disparador, la condición y el cambio dentro de la app. Le dice al constructor cómo debe verse el comportamiento fiable.

Si usas un constructor basado en chat, este tipo de redacción hace una gran diferencia. Las reglas claras no necesitan lenguaje legal. Necesitan palabras sencillas, una idea a la vez y un resultado esperado que quepa en una sola frase.

Escribir cálculos en lenguaje claro

Los cálculos a menudo parecen sencillos hasta que alguien intenta construirlos. La forma más segura es empezar con una oración en lenguaje claro que diga exactamente lo que la app debe hacer.

Una buena regla suena así: "El monto de reembolso es igual a las millas aprobadas multiplicadas por la tarifa por milla." Eso es mucho más claro que "calcular pago por viaje" o "aplicar reembolso estándar."

Después de esa primera oración, define cada entrada que la app debe usar. Sé lo suficientemente específico para que el constructor no tenga que adivinar.

Qué definir para cada cálculo

Para cada cálculo, especifica:

• las entradas, con nombres sencillos y unidades
• de dónde viene cada valor
• reglas de redondeo
• cualquier valor mínimo o máximo
• qué sucede si falta un valor

Los detalles pequeños importan. "Redondear el monto final a 2 decimales" da un resultado distinto a redondear cada línea primero. Si hay un tope, indica si la app debe detenerse en ese tope o mostrar una advertencia.

Una regla escrita en lenguaje claro podría verse así: "El reembolso de viaje es igual a millas aprobadas x $0.67. Redondear el monto final a 2 decimales. El reembolso máximo es $300 por viaje. Si millas aprobadas está en blanco, no calcular el monto. Marcar la solicitud como incompleta y pedir al usuario que ingrese las millas."

Luego añade uno o dos ejemplos resueltos con números reales. Los ejemplos exponen huecos más rápido que las fórmulas abstractas.

Ejemplo 1: "Si millas aprobadas es 120, el reembolso es 120 x $0.67 = $80.40. Como esto está por debajo del tope de $300, el monto final es $80.40."

Ejemplo 2: "Si millas aprobadas es 500, el reembolso es 500 x $0.67 = $335.00. Como el máximo es $300, el monto final es $300.00."

Este estilo es más fácil de revisar para las personas y más fácil para que un constructor lo convierta en comportamiento de la app.

Capturar excepciones sin confusión

La mayoría de las apps no fallan por la ruta principal. Fallan por los casos límite.

El camino normal puede ser simple, pero el trabajo real incluye reembolsos después de una fecha límite, clientes VIP, documentos faltantes y aprobaciones puntuales. Si se omiten las excepciones, la app rellena el hueco por su cuenta, y ahí es donde empiezan los resultados inconsistentes.

Una forma sencilla de escribir excepciones es usar reglas cortas del tipo si-entonces. Mantén cada una enfocada en una condición y un resultado.

• Si el gasto es menor a $100, entonces aprobar automáticamente.
• Si el gasto es menor a $100 pero se presentó después de 30 días, entonces enviarlo a revisión manual.
• Si el empleado está en el equipo ejecutivo, entonces omitir el límite de $100 y enrutar a finanzas.
• Si un admin de finanzas marca la reclamación como urgente, entonces aplica una anulación manual y la reclamación pasa al inicio de la cola.

Este formato hace visible la lógica oculta. También te ayuda a detectar solapamientos antes de que se conviertan en errores.

Igualmente importante, di qué regla gana cuando dos reglas chocan. Un cliente puede calificar para un descuento, pero el pedido puede caer en un periodo de blackout por vacaciones. Escribe la prioridad en lenguaje claro: "Si una regla de blackout por vacaciones entra en conflicto con una regla de descuento para el cliente, la regla de blackout prevalece."

Sé exacto sobre los límites. Fechas, tipos de usuario, ubicaciones, estado de cuenta y anulaciones manuales suelen cambiar el resultado. En lugar de escribir "las presentaciones tardías necesitan aprobación", escribe "Si una solicitud se presenta más de 14 días naturales después del evento, entonces se requiere aprobación del manager."

También indica qué debe mostrar la app al usuario en cada excepción. Una buena regla no se detiene en la decisión. También define el mensaje, por ejemplo "Presentado después de 14 días. Se requiere aprobación del manager" o "Anulación manual aplicada por admin de finanzas."

Cuando las excepciones se escriben así, los casos inusuales dejan de parecer inusuales. Se convierten en comportamientos normales y comprobables.

Describir la lógica de aprobación paso a paso

La lógica de aprobación funciona mejor cuando se escribe como una secuencia de decisiones, no como una política vaga. Cada paso debe responder cinco preguntas: quién actúa, qué dispara su revisión, qué límites aplican, cuánto tiempo tienen y qué estado obtiene la solicitud después de su decisión.

Empieza nombrando el rol, no solo el equipo. En lugar de escribir "finanzas revisa solicitudes grandes", escribe "El Finance Manager puede aprobar, rechazar o devolver cualquier solicitud que supere los $5,000." Eso elimina la adivinanza y hace el comportamiento más fácil de construir.

Luego define el disparador para cada paso. Un disparador es la condición que envía la solicitud a la siguiente persona. Puede basarse en monto, departamento, nivel de riesgo, tipo de solicitud o una mezcla de estos.

Por ejemplo:

• Si la solicitud es menor a $500, la revisa el team lead.
• Si la solicitud es de $500 a $5,000, el manager de departamento la revisa después de que el team lead apruebe.
• Si la solicitud es superior a $5,000, finanzas la revisa después de que el manager de departamento apruebe.
• Si la solicitud se marca como alto riesgo, compliance debe revisarla antes de la aprobación final.

Los umbrales necesitan límites exactos. No digas "grande" o "sensible". Di "por encima de $5,000", "del departamento de Sales" o "puntaje de riesgo 8 o más". Si dos umbrales pueden aplicarse al mismo tiempo, indica cuál prevalece. Por ejemplo: "Alto riesgo siempre va a compliance, incluso si el monto es bajo."

También necesitas una regla de tiempo de espera. Si nadie responde, la app no debe quedarse en limbo para siempre. Di qué ocurre tras un tiempo establecido, como 48 horas o 3 días hábiles. La solicitud puede escalarse al manager del aprobador, reasignarse a un aprobador de respaldo o cancelarse automáticamente.

Finalmente, define el estado tras cada decisión. Mantén las etiquetas cortas y consistentes:

• Aprobado: la solicitud avanza o se completa.
• Rechazado: la solicitud se cierra y no se toma más acción.
• Devuelto: el solicitante debe editar y volver a enviar.
• Escalado: la solicitud pasa a un aprobador de respaldo o superior.

Cuando la lógica de aprobación se escribe así, el constructor tiene menos margen para adivinar y el flujo se vuelve mucho más fiable.

Una plantilla simple que puedes reutilizar

Si quieres comportamiento consistente, dale a cada regla la misma forma. Los estilos de escritura mixtos suelen crear resultados mixtos.

Un formato simple funciona bien para la mayoría de los casos: disparador, condiciones, acción, resultado. Es lo bastante corto para escribir rápido y lo bastante claro para que alguien más lo revise después.

Usa una regla, una unidad

Mantén cada regla en su propia línea, tarjeta o bloque. No metas varias ideas en un mismo párrafo. Si una regla cubre precios, aprobación y una excepción a la vez, se vuelve difícil de probar y fácil de malinterpretar.

Un ejemplo práctico se ve así:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

No necesitas todos los campos cada vez. Pero mantener el mismo orden ayuda a que la gente escanee las reglas rápidamente.

Por ejemplo:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

Fíjate en que el ejemplo está debajo de la regla, no dentro de ella. Eso mantiene la regla limpia. El ejemplo solo demuestra cómo debe comportarse la regla.

Marca las suposiciones claramente en lugar de esconderlas en la frase. Una nota pequeña como "Suposición" o "Necesita confirmación" facilita revisar preguntas abiertas antes de la construcción.

También ayuda mantener tu redacción consistente. Empieza siempre los disparadores con "Cuando", las condiciones con "Si" y las acciones con "Entonces". Pequeños patrones como este reducen la confusión, especialmente cuando las reglas se convierten en lógica de app.

Una prueba rápida funciona bien aquí: ¿puede alguien probar esta regla y puede alguien malinterpretarla? Si la respuesta a la primera es no, o a la segunda es sí, ajusta la redacción.

Ejemplo: una app de aprobación de gastos

Una app de gastos de empleados es un buen caso de prueba porque la política es familiar y los casos límite aparecen rápido. El personal puede reclamar comidas, taxis, hoteles y pequeños gastos con clientes, pero cada reclamo tiene límites, excepciones y pasos de aprobación. Este es exactamente el tipo de proceso donde el lenguaje claro importa.

Política de ejemplo

Escribe la regla de comidas así: los empleados pueden reclamar hasta $40 por día por comidas en días laborales normales. La app debe sumar todos los recibos de comidas de la misma fecha y comparar ese total con el límite diario, no cada recibo por separado.

Si el empleado gasta $12 en desayuno y $22 en almuerzo el martes, el total es $34, así que el reclamo pasa. Si añade una cena de $15 el mismo día, el total se vuelve $49, por lo que la app debe marcar el reclamo como por encima del límite.

Ahora añade una excepción. Si la comida ocurrió durante un viaje de negocios aprobado o en una reunión con cliente, el límite diario de comidas aumenta a $75. Esa excepción solo aplica cuando el empleado selecciona Viaje = Sí o Reunión con cliente = Sí y añade una nota corta con el nombre del cliente o el propósito del viaje.

Esto es más fiable que un texto vago como "se pueden permitir casos especiales" porque la excepción está ligada a condiciones claras.

Pasos de aprobación

La lógica de aprobación puede mantenerse igual de clara:

• Los reclamos menores a $100 los aprueba el manager del empleado.
• Los reclamos de $100 a $500 necesitan aprobación del manager y luego de finanzas.
• Los reclamos por encima de $500 necesitan aprobación del manager, finanzas y el jefe de departamento.
• Cualquier reclamo marcado como "viaje" también necesita revisión de finanzas, incluso si el monto es inferior a $100.

Puedes probar la regla con unos pocos casos simples. Un reclamo de comida de $36 en un día laboral normal debería aprobarse si los recibos están adjuntos. Un reclamo de $60 en un día de viaje debería pasar si viaje está marcado y la nota está completa. Un reclamo de $60 en un día normal debería rechazarse o devolverse para corrección. Un reclamo de hotel de $650 debería pasar por los tres pasos de aprobación.

Ese es el objetivo: la regla debe producir el mismo resultado cada vez que alguien la pruebe con casos reales.

Errores comunes que conducen a malos resultados

Una regla puede sonar clara para una persona y aún así confundir a un constructor. Eso suele ocurrir cuando el documento es vago, mezcla varias ideas o es inconsistente de una línea a otra.

Un error común es amontonar varias reglas en un párrafo largo. Por ejemplo: "Los managers aprueban viajes a menos que el total sea alto, finanzas revisa recibos y las solicitudes urgentes pueden omitir revisión." Eso puede parecer eficiente, pero oculta varias decisiones separadas. Sepáralas en reglas distintas para que cada acción tenga un disparador y un resultado.

Otro problema es el lenguaje impreciso. Palabras como normal, grande, urgente o reciente solo funcionan si se definen. Si "gasto grande" significa más de $2,000, dilo. Si "urgente" significa necesario en 24 horas, escribe esa condición exacta.

Los datos faltantes son otra fuente importante de malos resultados. Los equipos suelen describir la ruta feliz y olvidan decir qué hacer cuando la información está incompleta o es incorrecta. Si una solicitud no tiene monto, ni departamento o ni recibo, la regla debe indicar qué sucede luego.

Los errores que más problemas causan suelen ser:

• combinar múltiples reglas en un solo párrafo
• usar términos indefinidos para tamaño, tiempo o prioridad
• olvidar casos de error y campos faltantes
• dejar la autoridad de aprobación final poco clara
• cambiar nombres para la misma cosa a mitad del documento

La autoridad final importa más de lo que muchos equipos esperan. Si un manager y un revisor de finanzas no están de acuerdo, ¿quién tiene la última palabra? Si nadie es responsable del paso final, la app puede atascarse o enviar trabajo en círculos.

Los cambios de términos crean errores silenciosos. Si empiezas con "solicitud" y luego la llamas "envío" o "ticket", los lectores pueden asumir que son cosas distintas. Elige un término y úsalo en todo el documento.

Esto importa aún más en un constructor basado en chat, donde el lenguaje claro dirige el comportamiento. Las reglas claras no necesitan sonar formales. Deben ser específicas, consistentes y completas.

Lista rápida antes de construir

Antes de convertir requisitos en pantallas, flujos o prompts, haz una última revisión corta. Un control ahora puede ahorrar horas corrigiendo comportamientos extraños después.

Haz cada regla comprobable. Cada regla debe terminar con un resultado claro como sí o no, aprobar o rechazar, aplicar tarifa o no aplicar tarifa. Si dos personas pueden leer la misma frase y dar respuestas distintas, la regla necesita trabajo.

Especifica cada cálculo. Nombra las entradas, la fórmula y cuándo ocurre el cálculo. Añade redondeo, moneda, manejo de fechas y qué debe pasar si un valor está ausente o es cero.

Mantén las excepciones separadas. Escribe la regla por defecto primero y luego agrega las excepciones por separado. El límite principal de gasto no debe esconderse dentro de un caso especial para contratistas, compras urgentes o viajes preaprobados.

Mapea todo el camino de aprobación. Para cada umbral, indica quién aprueba y qué sucede después. Sé exacto también en los límites: di si una regla empieza por encima de $500 o en $500 y más.

Luego haz la prueba del nuevo compañero. Da la regla a alguien que no haya trabajado en ella y pídele que te la explique con sus propias palabras. Si necesita contexto adicional, la regla sigue siendo demasiado vaga.

Un pequeño ejemplo muestra por qué esto importa. "Manager aprueba gastos grandes" suena claro hasta que alguien pregunta si $500 cuenta como grande. "Manager aprueba gastos por encima de $500. Director aprueba gastos por encima de $2,000. Gastos de $500 o menos se aprueban automáticamente" deja mucho menos margen de error.

Convertir reglas en una app funcionando

Una vez que las reglas están claras, revísalas con las personas que usan el proceso todos los días. Managers, coordinadores, personal de finanzas y aprobadores a menudo notan pequeños detalles que nunca llegan al documento de política. Esos detalles suelen ser lo que hace que una app se sienta ágil o frustrante.

Trata el documento de reglas como instrucciones de trabajo, no como un borrador de una sola vez. Debe explicar qué sucede, quién decide, cuáles son las excepciones y qué hace la app cuando falta información.

Antes de construir la app completa, prueba algunos escenarios reales del trabajo reciente. Usa casos limpios y casos desordenados: una solicitud estándar que debe pasar, una solicitud con información faltante, una excepción que necesita revisión manual y un caso que cruza un límite de gasto o un umbral de aprobación.

Este paso detecta huecos temprano. Una regla puede sonar clara en papel pero desmoronarse cuando una solicitud real no encaja en el patrón esperado.

Cuando esos escenarios se mantienen, pásalos a tu constructor. Si usas una plataforma basada en chat como Koder.ai, un conjunto de reglas claro hace que la construcción sea mucho más rápida porque estás traduciendo un proceso definido en pantallas, acciones y aprobaciones en lugar de tomar decisiones sobre la marcha.

Después del lanzamiento, conserva el documento como la fuente de la verdad. Cuando una política cambia, se añade un nuevo aprobador o se actualiza un límite, cambia el documento primero y luego actualiza la app. Eso mantiene las futuras ediciones más simples y reduce la probabilidad de que distintas personas recuerden la regla de formas diferentes.

Un pequeño hábito ayuda aquí: revisa las reglas siempre que el proceso cambie, no solo cuando la app falle. Pequeñas actualizaciones hechas temprano son mucho más fáciles que corregir un comportamiento confuso más tarde.

Si el documento se mantiene actualizado, la app se vuelve más fácil de probar, mejorar y confiar con el tiempo.