Automatizar una tarea y atribuir una decisión
La automatización permite ejecutar operaciones mediante reglas o sistemas sin intervención manual en cada paso. Puede utilizarse para registrar una solicitud, verificar consistencia de campos, calcular un resultado o producir una recomendación. Esas tareas no son jurídicamente equivalentes a conceder, negar, sancionar o resolver un recurso. Antes de valorar el sistema debe identificarse qué parte del procedimiento realiza, qué efecto produce y quién responde por la actuación. El hecho de que una operación sea rápida o se ejecute sin errores informáticos no acredita que su criterio sea jurídicamente válido.
Puede distinguirse automatización de apoyo, que facilita trabajo sin resolver por sí sola la pretensión; recomendación automatizada, que ofrece una propuesta al decisor; y producción automatizada de una decisión o efecto, cuyo régimen debe examinarse específicamente. Es una clasificación analítica para detectar riesgos y obligaciones, no una autorización legal por categorías. Una pantalla que dice «recomendación» puede, en la práctica, bloquear toda alternativa; una herramienta que calcula un plazo puede influir decisivamente en admisión. Debe estudiarse funcionamiento real y no únicamente etiqueta comercial.
Los artículos 121 constitucional y 57 del CPACA permiten separar atribución de la autoridad y formato electrónico. El segundo admite actos electrónicos con autenticidad, integridad y disponibilidad, pero no habilita por sí solo cualquier criterio sustantivo o procedimiento automático. La competencia y sus condiciones provienen del régimen correspondiente. Tampoco la norma exige que toda operación sea manuscrita: lo relevante es identificar fuente, naturaleza del acto, condiciones de producción y garantías aplicables, sin convertir digitalización en prohibición absoluta ni en permiso universal.
Reglas programadas y modelos de inferencia
Un sistema de reglas explícitas aplica condiciones programadas: por ejemplo, comprueba si un campo está vacío o calcula una suma. Su revisión necesita contrastar regla jurídica, traducción informática y datos de entrada. Si el programa exige un documento que la ley no requiere, ejecutar exactamente el código produce el error jurídico previsto por su diseño. Una prueba técnica que confirma funcionamiento del programa no demuestra conformidad normativa. Deben conservarse versiones y evidencia que permitan identificar qué regla operó en la actuación examinada.
Un modelo de inferencia puede producir una clasificación o estimación a partir de patrones y no solo de reglas jurídicas expresas. Una probabilidad de riesgo no demuestra que una persona incumplió una obligación. Deben examinarse propósito, calidad de datos, método, límites y uso del resultado. La Circular SIC 002/2024, leída completa, distingue sistemas que producen salidas o asisten decisiones y exige proteger datos en diseño, prueba, despliegue y seguimiento. Su regulación de tratamiento no convierte cada predicción en fundamento suficiente de una sanción pública.
Potestad reglada y margen de valoración
Una consecuencia reglada necesita comprobar todos los presupuestos pertinentes. No todo requisito se reduce a una casilla, y un dato ausente en una base no equivale necesariamente a incumplimiento probado. La implementación debe identificar excepciones, documentos admitidos y situaciones que requieren examen adicional conforme al régimen. Si el sistema solo representa el caso típico, puede producir negativas que la ley no permite. La solución no consiste en inventar excepciones por compasión, sino en traducir correctamente la estructura jurídica y conservar tratamiento de los supuestos que esa estructura contempla.
Cuando existe margen discrecional, el artículo 44 del CPACA exige adecuación a fines y proporcionalidad respecto de hechos. Un puntaje no reemplaza esa justificación ni crea atribución discrecional donde no existe. El sistema puede aportar insumos comparables, pero la decisión debe relacionarlos con circunstancias y régimen. Tampoco la intervención humana sanea automáticamente el resultado: firmar sin conocer el fundamento o repetir ciegamente una recomendación conserva el problema de motivación y valoración. La supervisión necesita capacidad real de verificar, corregir y asumir razones dentro de la competencia.
Prueba, motivación y posibilidad de contradicción
Los artículos 40–42 del CPACA regulan pruebas, corrección de irregularidades y decisión motivada con oportunidad de expresión. Si una herramienta produce un insumo determinante, debe examinarse cómo incorporarlo al expediente y permitir discusión conforme al régimen. La autoridad no puede responder únicamente que el algoritmo decidió y por ello no existen razones disponibles. No se afirma un derecho universal a publicar íntegramente todo código fuente: deben distinguirse información necesaria para comprender y controvertir la actuación, contenidos protegidos y mecanismos jurídicos de acceso y control.
La explicación de una decisión debe identificar hechos relevantes, reglas aplicadas y relación con la consecuencia. Mostrar un número sin explicar su papel puede ser insuficiente para esa finalidad. A la inversa, revelar miles de líneas de código no garantiza comprensión de por qué se usó un dato equivocado o se negó una prestación. El diseño debe conservar información sobre entradas, versión, regla o modelo y resultado cuando sea necesaria para reconstruir lo actuado, respetando protección de datos y conservación. Estas medidas concretan trazabilidad; su contenido técnico depende de función y riesgo.
La posibilidad de corregir datos y discutir decisiones requiere distinguir mecanismos. Un reclamo de rectificación bajo Ley 1581 no es idéntico a recurso administrativo contra un acto ni suspende automáticamente todos sus efectos. El sistema debe permitir encaminar cada solicitud y examinar consecuencias conforme al régimen. Si una negativa utiliza una condición desactualizada, puede ser necesario corregir base y estudiar el acto por su vía. Ni la existencia de un botón de reclamación prueba respuesta efectiva ni una mejora de interfaz modifica por sí sola términos y competencia para decidir.
Estándares de transparencia para sistemas comprendidos
La Directiva Conjunta 007 de 30 de septiembre de 2025, Procuraduría y Defensoría, establece estándares mínimos de transparencia algorítmica, no una ley general de habilitación decisoria. Sus artículos 1, 3 y 6 relacionan sujetos obligados de Ley 1712 con sistemas para uso del Estado que cumplan las condiciones: IA, sistemas de decisiones automatizadas según su definición o determinadas aplicaciones de rastreo por proximidad y monitoreo de riesgos. Deben contrastarse definiciones, exclusiones y alcance antes de afirmar que cualquier programa ordinario recibe idéntico tratamiento.
Los artículos 8–12 exigen divulgación de información del sistema y canales para revisiones y objeciones. Deben permitir identificar objetivo, función, estado, datos, desarrollador y responsables de contacto, con actualización y lenguaje comprensible. La transparencia activa informa sin esperar una solicitud; la pasiva atiende peticiones. El canal no es un recurso universal nuevo que sustituya todos los previstos para el acto: debe organizar respuesta y garantías conforme al régimen. No basta con publicar un correo si nadie asume la solicitud o explica quién puede resolverla.
Los artículos 13–14 identifican sistemas con mayores exigencias, como los usados para asignar o negar beneficios, predecir ciertos riesgos o generar perfiles, y requieren análisis de impacto algorítmico previo al despliegue en los supuestos enumerados. Se divulgan criterios, necesidad del uso, hallazgos, mitigación y vías de objeción según sus términos. Ese análisis no equivale al estudio de impacto de privacidad de SIC ni permite omitirlo cuando corresponda; tienen objetos y presupuestos propios. Tampoco su realización convalida una competencia ausente o una causal de negativa no prevista.
Gestión de riesgos y conservación de responsabilidad
La automatización puede reproducir errores a escala. Una regla defectuosa que afecta un expediente puede repetirse en muchos si no existen seguimiento y corrección. El análisis de riesgo debe considerar gravedad, probabilidad, alcance, capacidad de detectar el error y posibilidades de reparación. No es suficiente medir cantidad de decisiones por minuto. Un aumento de velocidad acompañado de negativas infundadas no acredita cumplimiento de función administrativa. Los principios del artículo 3 del CPACA y derechos constitucionales integran la evaluación junto al desempeño operativo.
La evaluación debe continuar después de poner el sistema en uso: pueden cambiar datos, normas o condiciones del servicio. Registrar incidentes, revisar resultados y conservar una vía de corrección reduce el riesgo de aplicar indefinidamente criterios desactualizados. Un proveedor puede colaborar, pero la autoridad no se libera de sus deberes por haber comprado la solución. Las obligaciones de responsables y encargados de datos de los artículos 17–18 de la Ley 1581 deben identificarse, sin asumir que todo participante cumple el mismo papel o que un contrato elimina derechos del titular.
Ejemplo colombiano 1: recomendación convertida en negativa inevitable
Una herramienta estima riesgo de inconsistencia y el procedimiento interno ordena negar siempre que aparezca alerta, sin verificar hechos ni permitir examinar documentos. Aunque el sistema se denomine apoyo, su resultado determina realmente la decisión. Deben comprobarse regla jurídica, evidencia y oportunidades de intervención; la alerta no equivale a prueba suficiente de incumplimiento. Puede organizarse verificación conforme al régimen, sin convertir una probabilidad en nueva causal de negativa. El ejemplo presupone un procedimiento administrativo general y no inventa una autorización sectorial de sanción algorítmica.
Ejemplo colombiano 2: regla informática sin una excepción legal
Un sistema aplica una condición y su equipo sabe que el régimen contiene una excepción pertinente, pero no la representa ni permite remitir casos para examen. Una persona acredita el supuesto exceptuado y recibe negativa automática. Deben corregir la traducción de la regla y encaminar revisión de la decisión por la vía aplicable. La coincidencia del programa con su especificación técnica no demuestra legalidad de esa especificación. El ejemplo enseña estructura de regla y excepción, sin atribuir una excepción real a un sector no investigado.
Ejemplo colombiano 3: puntaje y firma sin razones
Una funcionaria firma una decisión discrecional que solo dice «puntaje insuficiente» y afirma que su firma garantiza motivación. Debe reconstruirse qué valor mide, qué hechos se acreditaron y por qué la consecuencia es adecuada al fin y proporcional según el artículo 44. La firma no reemplaza esa relación, del mismo modo que usar un modelo no vuelve inválido cualquier insumo técnico. La autoridad necesita capacidad de valorar y explicar, y el interesado debe disponer de garantías pertinentes para discutir hechos y aplicación normativa dentro del procedimiento.