Tag: Inteligencia artificial

Un proyecto en la Cámara propone que los data centers de IA pongan su propia luz.

¿Pero quién decide dónde serán instalados?

En nuestros dos artículos anteriores sobre data centers de Inteligencia Artificial, los cuales puedes leer aquí y aquí, discutíamos si Puerto Rico debía aprobar reglas específicas para los data centers antes de que llegara la primera solicitud de permisos. Esta pregunta fue contestada parcialmente el pasado 15 de octubre de 2026, cuando los representantes Jerry Nieves Rosario (PNP), Luis J. Jiménez Torres (PNP) y Jorge “Georgie” Navarro Suárez (PNP) radicaron la “Ley para el Desarrollo de la Infraestructura de Cómputo e Inteligencia Artificial de Puerto Rico”, P. de la C. 1523. El mismo fue asignado a la Comisión de Gobierno de la Cámara. No es ley.

Este no es el primer proyecto que toca los data centers en Puerto Rico. El Código de Incentivos de Puerto Rico (Ley 60-2019) ya reconoce como elegibles los centros de procesamiento electrónico de información, la distribución por computación en la nube y los “centros de servicios de desarrollo para el procesamiento y almacenamiento de datos”. Lo que hace el P. de la C. 1523 es distinto: es el primer proyecto que ata por primera vez los incentivos a condiciones de servicio eléctrico.

Lo leímos completo. El proyecto habla mucho de incentivos y electricidad, pero poco de dónde se construirían los centros y cuánto podría opinar el público sobre ellos.

A continuación, Farrant Te Explica el P de la C 1523.

¿Qué propone?

El Artículo 2 del Proyecto de ley establece como política pública “promover el establecimiento y la expansión en Puerto Rico de centros de datos y de cómputo para inteligencia artificial, como actividad industrial de alto valor tecnológico, y la exportación de sus servicios”, siempre que no se trasladen costos a los demás clientes de la red eléctrica, que los centros cuenten con capacidad propia de generar energía en condiciones de insuficiencia, que se proteja el agua y que haya beneficios verificables para el país.

El Proyecto busca implementar esta política pública en dos niveles.

Nivel 1: reglas para todo centro de 5 MW o más. Aplican con o sin incentivos a todo “Centro de Datos de Carga Grande” que solicite servicio eléctrico nuevo o ampliado (Art. 8). Un megavatio (MW) equivale a la demanda aproximada de cientos de hogares. Estos centros tendrían que:

  • Contar con capacidad firme propia de al menos 100% de su carga en operación, certificada por el Negociado de Energía (“Negociado”), y no operará por encima de esa capacidad certificada.
  • No tomar energía de la generación del sistema durante alertas de reserva, relevos de carga y emergencias.
  • Sufragar todos los estudios, interconexión y mejoras a la red eléctrica atribuibles a su servicio.
  • Comprar energía de la red solo dentro de bloques adjudicados por convocatoria (Art. 11).
  • Usar enfriamiento en circuito cerrado, por aire, con agua reusada o no potable. El agua potable de la Autoridad de Acueductos y Alcantarillados (AAA) sólo podrá usarse hasta el límite que ésta fije, en consulta con el Departamento de Recursos Naturales y Ambientales (DRNA) (Art. 7(a)).

Para sumar las cargas, se contarán las instalaciones de una misma persona o sus afiliadas que se encuentren en el mismo predio, en predios contiguos, o que se sirvan de la misma subestación. El Proyecto excluye de esta definición las telecomunicaciones y estaciones de aterrizaje de cables submarinos (Art. 3(l)).

Nivel 2: el precio de los incentivos. La persona o entidad que quiera recibir un decreto bajo el Código de Incentivos tendrá que asumir el “Compromiso Megavatio” (Arts. 4 a 6 y 14 a 17), el cual establece que:

  • Además de su capacidad firme propia, mantener una reserva para la red de al menos 50% de su carga en operación, disponible para inyectar cuando el operador la pida. La compensación no podrá exceder el costo evitado del sistema.
  • Suplirá al menos 50% de su consumo con energía renovable adicional al sexto año, con un PUE (“Power Usage Effectiveness”) de diseño no mayor de 1.3. El PUE mide cuánta energía total gasta el centro por cada unidad que consumen los equipos de cómputo.
  • El centro se diseñará para resistir huracanes con vientos de categoría 5 y  operar aislado de la red eléctrica.
  • Reservará al menos 5% de su capacidad de cómputo – o una porción equivalente de espacio, energía y enfriamiento – a costo, para la UPR, el gobierno y emprendedores, bajo el “Banco de Cómputo Soberano” (Art. 14).
  • Firmará un acuerdo con el municipio sede para aportarle 25% de las contribuciones sobre la propiedad y patentes municipales que quedan exentas. El Artículo 15(b) aclara que esta aportación “constituirá una obligación contractual del concesionario y no una contribución municipal”.
  • Informará cada año al Departamento de Desarrollo Económico y Comercio de Puerto Rico (“DDEC”) y al Negociado de Energía su consumo total de energía, la que toma de la red y la que inyecta, las solicitudes del operador que atendió, su PUE y su WUE (“Water Usage Effectiveness”), el porcentaje de energía renovable adicional, el uso del Banco de Cómputo Soberano y su empleo directo (Art. 17(a)). 

Los centros que ya existen podrían expandirse con una tasa fija de 2% sobre el ingreso de exportación atribuible a los primeros 20 MW añadidos, durante 10 años, y exenciones de ventas y uso (Arts. 9, 20 y 21). Si la carga añadida llega a 5 MW, las reglas del Nivel 1 aplicarían solo a esa carga incremental, no a la carga base. 

Cómo se obtendría un decreto. El DDEC, en coordinación con el Negociado, adjudicaría por convocatoria los bloques de capacidad del sistema y el derecho preferente a contratar predios y puntos de interconexión (Art. 11). El Secretario del DDEC podrá designar “Zonas de Cómputo y Energía” en terrenos con infraestructura de transmisión existente o planificada, incluyendo terrenos de Fomento Industrial y la Autoridad de Energía Eléctrica (AEE) (Art. 12). Los proyectos en esas zonas, y las expansiones con decreto, tramitarían permisos bajo el proceso especial de la sección 6070.69 del Código de Incentivos.

El Negociado de Energía tendría 180 días desde la aprobación de la ley para adoptar un reglamento. Hasta que eso ocurra, el operador de la red no podría aprobar servicio nuevo o ampliado para estos centros sin autorización previa del Negociado (Art. 8(c)).

Lo que el Proyecto sí atiende

El proyecto aborda el problema que describe su exposición de motivos: la red de Puerto Rico no tiene excedentes de energía para data centers de IA. Según la exposición de motivos, la demanda pico de electricidad en el verano de 2026 rondó los 3,234 MW, con generación disponible cerca de 3,200 MW, y hubo 15 relevos de carga manuales entre julio y agosto. La tarifa de electricidad récord de 33.86 centavos por kWh entró en vigor el 1 de octubre de 2026, la cual es casi el doble del promedio residencial de 18.3 centavos por kWh en Estados Unidos.

Esta difícil realidad de nuestro sistema eléctrico se vivió esta misma semana en que sale este artículo. El martes 27 de octubre, según El Nuevo Día, LUMA Energy advirtió que más de 100,000 clientes podrían sufrir apagones por déficits de generación durante la noche, tras perderse unos 270 MW por la salida de la unidad 5 de San Juan y las limitaciones de la unidad 2 de Aguirre. A las 8:00 p.m., el portal de LUMA reportaba 140,841 abonados sin servicio por este déficit. Según un portavoz de LUMA, aun con ambas unidades de vuelta y las baterías residenciales inyectando, la reserva proyectada sería de apenas 20 MW. Mientras escribimos este párrafo, no hay luz en nuestra casa.

Captura del portal de LUMA Energy (lumapr.com) tomada por nosotros el martes 27 de octubre de 2026 a las 8:26 p.m. Muestra una capacidad disponible de 2,612 MW, una carga pronosticada de 2,737 MW para una reserva total de −125 MW.

Es en esta red donde el Negociado tendrá que certificar la capacidad firme propia de cada data center (Art. 8(a)(1)), vigilar que nadie tome energía del sistema durante alertas, relevos de carga (como los apagones selectivos del 27 de octubre) y emergencias (art. 8(a)(2)) y recibir sus informes anuales (Art. 17). 

Frente a esta realidad, el Proyecto propone 3 cosas que ningún instrumento local hace hoy:

  1. Prohíbe trasladar costos a los demás clientes (Art. 8(a)(4)).
  2. Exige que los centros traigan su propia energía en vez de competir por la existente.
  3. Restringe el agua potable para enfriamiento y ordena informes y garantías financieras por megavatio, a favor del Gobierno, que se ejecutarían en caso de incumplimiento (Art. 8(b)(7)).

Lo que el proyecto no menciona

  • Participación ciudadana. No contiene requisitos de notificación al público, celebración de vistas públicas o intervención de la comunidad sobre dónde se construiría un centro. El único mecanismo local que menciona el Proyecto es la aportación municipal del Artículo 15. Aquí hay un detalle importante: si el municipio no firma el acuerdo con la entidad en 60 días, el Art. 15(c) permite al DDEC  emitir el decreto con esa aportación como condición a favor del municipio. Por consiguiente, el proyecto le permite al DDEC sustituir la voluntad municipal.  Quedará por verse si esto es compatible con la autonomía municipal que protege la Ley 107-2020 – cuyo Art. 1.007 invoca el propio proyecto – ya que, hasta donde pudimos verificar, no conocemos un caso donde se haya litigado esta controversia. Además, para los decretos, la Ley 60 ya dispone que las decisiones del Secretario del DDEC sobre la aprobación de una solicitud de incentivos y su contenido son finales, sin revisión judicial ni administrativa ni otro recurso, y que, una vez otorgada la concesión, ningún municipio ni agencia puede impugnar su legalidad (Sec. 6020.01(k)). El proyecto no cambia esta regla, ya que el Artículo 18(c) la mantiene “sin menoscabo”. Esto podría complicar una impugnación basada en la autonomía municipal. 
  • Transparencia. El DDEC publicaría los informes de los centros con decreto, salvo la información comercial confidencial. Los centros de 5 MW o más que no posean un decreto sólo tendrán que informar su consumo de agua y energía al Negociado, y el proyecto únicamente dice que éste protegerá la información comercial confidencial (Art. 17). No ordena la publicación de estos informes. Tampoco define qué es “información comercial confidencial”, lo cual deja abierta la posibilidad de que información de datos de consumo – los cuales son de interés público en un sistema en crisis – queden fuera del alcance del público por decisión administrativa.
  • Ambiente. No exime de las leyes ambientales (Arts. 7(c) y 13(b)), pero tampoco las refuerza. Guarda silencio sobre el calor que un centro libera al ambiente y no establece un tope de consumo consuntivo de agua, solamente el deber de informar el WUE y consumo anual de agua (Art. 17(c)). Por otro lado, el límite de consumo de agua potable lo fijará la AAA, es decir, la entidad que vende el agua, “en consulta con” el DRNA. 
  • Permisos. El Artículo 13 acelera la aprobación de permisos, pero conviene ser preciso sobre cómo lo hace. Su apartado (b) dice que no se alteran los requisitos sustantivos ni exime del cumplimiento ambiental. Sin embargo, el Artículo crea una ficción jurídica al ordenar tramitar estos proyectos “como si se tratara de Proyectos Prioritarios en Zonas de Oportunidad”. Es decir, podría darse el caso de que se active el trámite especial aunque el predio no esté en una Zona de Oportunidad formalmente designada. La pregunta que queda sin contestar aquí es de tiempo, no de sustancia: ¿se podrá hacer y evaluar rigurosamente el impacto ambiental de un proyecto dentro de los plazos abreviados que este proceso conlleva?

El Proyecto tiene un defecto de redacción: usa dos nombres distintos para esta ley.

El Art. 1 bautiza el Proyecto como “Ley para el Desarrollo de la Infraestructura de Cómputo e Inteligencia Artificial de Puerto Rico”. Sin embargo, los Artículos 20(b) y 21 (g) con enmiendas al Código de Incentivos, remiten a la “Ley del Pacto Megavatio para el Desarrollo de la Infraestructura de Cómputo e Inteligencia Artificial de Puerto Rico”. 

Son dos nombres distintos para la misma ley. Y, como las nuevas secciones propuestas aquí dependen de esa remisión para definir sus términos y condiciones, el error deja a estas secciones citando una ley que no existe. Esto es un error que se puede corregir en el trámite, pero que deseamos señalar ahora, para que se haga la corrección.

El choque entre el DDEC y el Negociado que crea el Proyecto

Según nuestra lectura, el Proyecto reparte las decisiones sobre los centros entre 2 agencias con mandatos distintos, y esa división merece preguntas en vistas públicas. 

El Artículo 11(a) dispone que el DDEC “en coordinación con el Negociado”, adjudicará mediante convocatorias públicas y competitivas, por bloques de megavatios: (1) el derecho preferente a contratar los predios y puntos de interconexión disponibles en las Zonas de Cómputo y Energía, y (2) los bloques de capacidad del sistema eléctrico para que los centros de carga grandes compren energía fuera de una alerta de reserva. Sobre los bloques de energía, el Negociado otorgará “la autorización correspondiente” y, antes de cada convocatoria, certificará el margen de reserva disponible y tamaño máximo del bloque. Además, certificará la capacidad firme propia de cada centro (Art. 8(a)(1)), autorizará caso por caso mientras adopta un reglamento (Art. 8 (c)) y tiene jurisdicción para imponer penalidades (Art. 8(a)(6)). 

Por otro lado, según el texto del Proyecto, un centro de carga grande no puede comprar energía de la red fuera de una alerta sin un bloque que el Negociado autorice (Art. 8(a)(3)). Sin embargo, el DDEC – cuyo mandato es atraer y retener inversión – es quien designa las Zonas (Art. 12(a)) y quien adjudica los predios. Los factores que enumera el Art. 11 (b) para evaluar propuestas son la reserva ofrecida, los renovables, la eficiencia, inversión, empleo y contribución al Banco de Cómputo Soberano. No menciona nada sobre aceptación de la comunidad al Proyecto o impacto ambiental del sitio, aunque la lista incluye “entre otros factores”.  

Esta decisión de diseñar la implementación del Proyecto no está justificada en ningún lugar, y deja una pregunta práctica sin contestar. El texto exige “coordinación” entre el DDEC y el Negociado, pero, ¿qué ocurre si discrepan? Por ejemplo, podría darse un caso en el que el DDEC adjudica un predio a un centro y el Negociado no autoriza el bloque de energía que ese centro necesita. Esto será necesario preguntar y aclarar en las vistas públicas, junto con otra pregunta: ¿por qué no debería conducir las convocatorias el Negociado, el regulador que existe para proteger a los abonados, con el DDEC en un rol de  promocionar la inversión?

El Artículo 4(e) sólo deja 1 puerta para los incentivos

El Artículo 4(e) dispone que, desde la vigencia de la ley, no se otorgará decreto alguno bajo cualquier capítulo del Código de Incentivos que cubra total o parcialmente la operación de un Centro de Datos de Carga Grande, salvo como Centro de Cómputo Cualificado (Art. 4) o como expansión de un Centro de Datos Existente (Art. 9). Esta regla no aplica a solicitudes de decreto presentadas antes de la vigencia de la ley. Asimismo, el Artículo 23(a)(8) exime del impuesto sobre ventas y uso (IVU) y de los arbitrios estatales el equipo de un Negocio Exento que opere un Centro de Cómputo Cualificado con decreto.

Mientras tanto, las reglas del Nivel 1 aplican a todo centro de 5 MW o más “posea o no un Decreto” (Art. 3(l)). Por ende, un centro que no quiera asumir el Compromiso Megavatio no recibirá incentivos contributivos, pero sí tendría que cumplir con el Nivel 1. Asimismo, puede competir por los bloques de capacidad que necesita para comprar energía de la red, y la adjudicación no conlleva un decreto (Arts. 8(a)(3) y 11 (d)).

El resultado aquí es que, en la práctica, el incentivo contributivo queda atado a un solo paquete. Quien lo rechace asumirá el Nivel 1 sin incentivos. Quien lo acepte, asumirá además la reserva para la red, las renovables adicionales, el Banco de Cómputo Soberano y la aportación municipal. Sería útil preguntar en vistas públicas si este diseño fue intencional, o si es un efecto no previsto de disposiciones redactadas por separado, y si lo que se exige en el Nivel 2 es proporcional a lo que se ofrece. 

La comparación internacional es diferente a que lo que dice la exposición de motivos

El proyecto presenta en su exposición de motivos los casos de Irlanda, Texas y Singapur, para luego señalar que esta propuesta ley “adopta lo mejor de esas experiencias y lo adapta a la realidad de Puerto Rico […]”.  Sin embargo, la realidad es más matizada. Veamos:

  1. Irlanda: Puerto Rico sería más laxo. La Comisión para la Regulación de Servicios Públicos (CRU) de Irlanda adoptó su política de conexión para grandes usuarios el 12 de diciembre de 2025 (CRU2025236). Esta exige que los data centers de 1 MVA o más suplan al menos 80% de su demanda anual con energía renovable adicional generada en Irlanda, dentro de seis años, y que los sitios de 10 MVA o más aporten generación o almacenamiento despachable, con medición separada, capacidad igual a su capacidad máxima de importación y participación obligatoria en el mercado. Bajo este proyecto, Puerto Rico pediría 50% al sexto año (Art. 6(a)). Sería prudente preguntar cómo se llegó a la cifra de 50% y por qué no se copió la de 80%.
  2. Texas: Puerto Rico sería más estricto. La SB 6 se firmó en Texas el 20 de junio de 2025 y aplica a cargas de 75 MW o más. Esta exige sufragar los costos de interconexión, acreditar el control del terreno y la solvencia financiera, y aceptar la desconexión durante eventos de firm load shed. Sin embargo, esa ley no requiere autosuministro. Puerto Rico sí.
  3. Singapur: Puerto Rico copia su mecanismo. Singapur asignó 200 MW de capacidad nueva a cuatro operadores en agosto de 2026 mediante su segunda convocatoria competitiva (Data Centre – Call for Application), con el requisito de que más de 50% de la capacidad se alimente de fuentes de energía verde y con PUE de 1.3 o mejor a plena carga de equipo de TI, además de tecnologías de enfriamiento líquido y equipo de TI 100% eficiente. El umbral de PUE coincide casi exactamente con el del Art. 6(b) del proyecto, y el porcentaje de energía verde es comparable al 50% del Art. 6(a). Más importante: la convocatoria competitiva del Art. 11 es precisamente el mecanismo que Singapur usa. En ese aspecto, el proyecto no improvisa, sino que copió a Singapur.

Con esto en mano, podemos decir que, en cuanto a lo que se refiere a capacidad firme propia, el P. de la C. 1523 es más exigente que Texas y comparable a Irlanda. En cuanto al uso de energía renovable, es más débil que Irlanda. Y, en eficiencia y en el mecanismo de asignación, va a la par con Singapur. No es “lo mejor de cada modelo”, como señala la exposición, sino una mezcla sin análisis explicativo.

¿Dónde deja este proyecto al propuesto Código de Permisos?

El Artículo 13 manda que los proyectos en Zonas de Cómputo y Energía, y las expansiones con decreto, tramiten permisos bajo el proceso de la Sección 6070.69 del Código de Incentivos “como si se tratara de Proyectos Prioritarios en Zonas de Oportunidad”.Ese proceso ya existe en la Ley 60: la notificación incluye un aviso en 2 periódicos y un rótulo, agencias y municipios tienen 10 días laborables para comentar (y si no lo hacen, la propuesta se entiende favorable), el documento ambiental se evalúa en 20 días laborales y la revisión judicial se solicita en 20 días naturales jurisdiccionales.

Por otro lado, el Código de Planificación y Permisos (P. del S.1173) aprobado por el Senado (que aún no es ley) considera estratégicos los Proyectos Prioritarios en Zonas de Oportunidad que cumplan con la elegibilidad de la Ley 60 (Art. 2.06(d)). Estos proyectos estratégicos estarían en la categoría de “Proyectos de Impacto Socioeconómico Prioritario”, a los que el Art. 12.40 del propuesto Código les aplica un trámite especial. Se presentan directamente ante la Oficina Central de Permisos, aunque el municipio tenga jerarquía delegada; la notificación se hace mediante un rótulo de presentación; las agencias y municipios tienen 20 días naturales para emitir recomendaciones (10 más si el análisis ambiental es complejo), y el municipio afectado, 20 días laborables para su consulta formal; la determinación final se emite en 10 días naturales tras culminar las recomendaciones; y la revisión judicial debe solicitarse en 20 días jurisdiccionales, sin paralización de la obra salvo que un tribunal la ordene para prevenir un daño irreparable. Si el “como si” del Artículo 13 basta para cumplir con la elegibilidad de la Ley 60, un data center podría ser considerado bajo esta vía.

Aquí queremos aclarar algo sobre las Zonas de Oportunidad, las cuales son una designación contributiva federal. Según las guías federales, las designaciones originales de Puerto Rico terminan el 31 de diciembre de 2027, un año antes que las del resto de Estados Unidos. El nuevo mapa dependerá de nominaciones y no cubrirá automáticamente toda la isla. Para este Proyecto, este cambio importa menos de lo que parece: como el Artículo 13 usa la fórmula “como si se tratara”, activar su trámite no requiere que el predio esté realmente en una zona de oportunidad. Sin embargo, el mapa sí podría importar si se quisiera además acceder a la vía estratégica del Código de Permisos, ya que la elegibilidad de la Ley 6 exige una zona federal designada y la designación del comité. 

¿Y cómo trataría este proyecto a uno como Seabase?

Un clúster de 10 a 20 MW como el que consideró Seabase en nuestro reciente artículo estaría cubierto, ya que las cargas se suman. Seabase nos dijo que evalúa combinar cómputo con nueva generación y baterías, lo cual encaja con la exigencia de capacidad firme propia. Por consiguiente, pareciera ser que, bajo este proyecto, si se convierte en ley, un desarrollo como el Seabase podría obtener los permisos y sus  incentivos contributivos. 

Detalles por verificar

  • Salida de la convocatoria. Un solicitante que se autoabastezca por completo, no se encuentre en una Zona de Cómputo y Energía y no compre energía de la red puede pedir su decreto en cualquier momento, sin convocatoria (Art. 11(c)). Sin embargo, no queda exento del Compromiso Megavatio ni de mantener la interconexión necesaria para inyectar su reserva.
  • Efecto fiscal sin cuantificar. La propia exposición de motivos dice que habrá que estimarlo durante el trámite. Es necesario que esta cifra se presente antes de votar, ya que el proyecto baja la tasa contributiva de 4% a 2% para el ingreso de exportaciones incremental y añade exenciones de IVU y arbitrios. En el contexto de déficit fiscal y situación económica que vive Puerto Rico, alguien tendrá que pagar esa diferencia. 
  • Tarifas especiales. El Proyecto no establece que los data centers pagarán tarifas especiales de agua y luz por su alto consumo, contrario a lo que está ocurriendo en varios estados y la Unión Europea, como mencionamos la semana pasada.
  • Reglamentos pendientes. Casi todo lo operativo queda relegado a los Reglamentos que el Negociado, el DDEC y la AAA tendrán que adoptar en 180 días luego de aprobarse la ley. Hasta entonces, el Art. 8(c) pone al Negociado a autorizar caso por caso. 
  • Vigencia escalonada. El Art. 28 dispone que los decretos como centro de Cómputo Cualificado y las enmiendas al Código de Incentivos solamente podrán otorgarse una vez entren en vigor los reglamentos de los Artículos 8 y 24(a). Es decir, aun si la ley se aprobara hoy, comenzaría realmente a operar en 180 días, o cuando lleguen los reglamentos.

¿Qué puedes hacer?

El proyecto apenas empieza su trámite legislativo, así que hay tiempo para conocer más y opinar. Toda vez que las aprobaciones de derechos no se pueden impugnar (Sec. 6020.01(k) de la Ley 60), el momento de participar es ahora, en la Legislatura y los reglamentos. 

Puedes seguir este proyecto en SUTRA, presentar una ponencia si la Comisión de Gobierno celebra vistas y contactar a tus legisladores.

Luego de la revisión de esta versión inicial del Proyecto, nos parece importante que se considere la revisión de las siguientes tres cosas:

  1. Que el Negociado celebre vistas públicas antes de designar una Zona de Cómputo y Energía. El Art. 12 actual permite al Secretario del DDEC designarlas en consulta con la Junta de Planificación, el Negociado y la AEE, sin participación de las comunidades afectadas.
  2. Que se elimine o enmiende el reloj de 60 días del Artículo 15(c) para que el DDEC no pueda imponer unilateralmente una aportación a un municipio que se negó a negociarla.
  3. Que se publique la cifra del efecto fiscal del proyecto antes de su votación final, no después.

Si crees que el proyecto debe incluir participación comunitaria vinculante, este es el momento de pedirlo. Además, puedes suscribirte a nuestro Substack Farrant Te Explica, donde estaremos cubriendo los avances de este proyecto. 

¿Cambiaría el nuevo Código de Permisos aprobado por el Senado de Puerto Rico el proceso de aprobación de un data center de IA bajo el mar?

En un artículo reciente, hablamos con los directores de la compañía Seabase y explicamos su interés en explorar la instalación de data centers de Inteligencia Artificial submarinos en aguas de Puerto Rico, y cómo el Reglamento Conjunto y las leyes vigentes podrían aplicarse a un proyecto novedoso como éste. Sin embargo, este análisis podría potencialmente cambiar significativamente, si se convierte en ley el Código de Planificación y Permisos recientemente aprobado por el Senado de Puerto Rico. Este Código es un proyecto de ley de 868 páginas que reescribe cómo se aprobarán proyectos en Puerto Rico. 

Una revisión de este proyecto de ley revela que el mismo no menciona data centers ni una sola vez. Por consiguiente, cualquier propuesta similar a la de Seabase se evaluaría con reglas generales, y el resultado dependería de la ruta que tome. En este artículo, Farrant Te Explica cómo este Código, si se convierte en ley según está redactado, podría considerar estas propuestas.

¿Qué es este Código?

El Código aprobado por el Senado el 13 de octubre de 2026 fue una versión “sustitutiva” que reemplazó los proyectos del Senado 1173 y 1183. Este reúne en un solo Código reglas dispersas en más de 50 leyes (Primera Hora). Propone además crear la “Oficina Central de Permisos”, adscrita al Departamento de Desarrollo Económico y Comercio (“DDEC”), para ser la entidad que recibirá y considerará solicitudes de permisos y una Junta Adjudicativa. Además, ordena en los artículos 7.02 y 7.03 a la Junta de Planificación y Urbanismo a redactar el “Reglamento Único de Planificación y Permisos de Puerto Rico” (“Reglamento Único”), el cual sustituiría al Reglamento Conjunto. Al 13 de octubre, La Fortaleza no había decidido si lo firmaría de aprobarlo la Cámara, y la medida actualmente enfrenta oposición multisectorial, la cual incluye sectores del ambiente, ciencia y planificación.

¿Bajo qué ruta se evaluaría este Proyecto?

Es difícil imaginar un data center submarino como un uso permitido que se aprobaría “de forma ministerial”, es decir, automática. Para proyectos como éste, el Código mantiene la Consulta de Ubicación, la cual define que se hará cuando proyectos propongan “un uso que no esté permitido ministerialmente o que requiera un cambio en la planificación en un terreno no desarrollado, o cuando así se requiera por este Código o por el Reglamento Único conforme a criterios objetivos previamente establecidos para proyectos que, por su naturaleza, complejidad, localización o posibles impactos, requieran un grado mayor de análisis” (Art. 12.24). Este mismo artículo establece que los procesos de evaluación y adjudicación “podrá[n] incluir la celebración de una vista pública”, es decir, discrecional como actualmente ocurre bajo el Reglamento Conjunto. 

Así las cosas, veamos las rutas por las que podría navegar este proyecto bajo este Código, si se convierte en ley según escrito.

Ruta 1: Consulta de Ubicación y revisión ambiental

Si el proyecto toma este curso, esto es lo que significaría para el público:

  • Notificación. Rótulo de presentación, carta certificada a los colindantes y aviso al municipio y a los municipios a menos de 200 metros (Arts. 12.34, 12.50 y 12.51). Esos municipios tendrán 15 días para presentar recomendaciones, las cuales no son vinculantes. El rótulo debe instalarse “en el terreno o estructura objeto de la solicitud”, y si el terreno colinda con un cuerpo de agua, también se notifica al dueño al otro lado. Esto nos lleva a preguntarnos lo siguiente: ya que este proyecto será en el mar, ¿dónde se instalaría el rótulo y quiénes serían los colindantes que recibirían la notificación?
  • Vista pública. El proceso “podrá incluir” una vista, según establezca ese futuro Reglamento Único. Por consiguiente, hasta ahora, sería discrecional.
  • Revisión ambiental. El proyecto pasaría por exclusión categórica, Evaluación Ambiental (EA) o Declaración de Impacto Ambiental (DIA). La exclusión y la EA no admiten intervenciones de terceros. El Código también presume que una acción que cumpla los parámetros aplicables no genera impacto significativo que requiera DIA. Y aun cuando se requiera una DIA, el Código requiere publicarla para comentarios, pero la vista pública solo se celebrará “cuando aplique” (Arts. 12.36 a 12.39).
  • Participación. El Código propone la creación de un registro público de todas las solicitudes, con acceso a copias de los documentos públicos. También permite que cualquier persona con interés legítimo pida ser parte interventora (Art. 12.52). Los mecanismos concretos para intervenir serán definidos en el Reglamento Único.

Ruta 2: La Vía Prioritaria

El Código propone la creación de “Proyectos de Impacto Socioeconómico Prioritario”. Estos podrían ser, entre otros, proyectos de generación, transmisión y distribución de energía aprobados por el Negociado de Energía, proyectos designados como estratégicos y los que designe la gobernadora. Un comité compuesto por el DDEC, Junta de Planificación y Urbanismo y un designado de la gobernadora determinará cuáles son estratégicos. El Art. 2.06(d) establece además que los Proyectos Prioritarios en Zonas de Oportunidad bajo la Ley 60 serán considerados como estratégicos.

Para estos proyectos “prioritarios”, el trámite propuesto sería el siguiente:

  • Se presenta directamente ante la Oficina Central de Permisos, aunque un municipio tenga jerarquía delegada.
  • Las agencias y municipios tendrán 20 días naturales para emitir recomendaciones. Si no contestan, se entiende que no tienen recomendaciones o comentarios. El municipio afectado deberá ser consultado formalmente en el término de 20 días laborables.
  • Para infraestructura no crítica, incluyendo la estratégica, la determinación ambiental se emitirá en 10 días naturales tras el término de recomendaciones. Los estratégicos pueden recibir el mismo trato ambiental que los proyectos críticos establecidos bajo la ley PROMESA, los cuales podrían presentarse como exclusión categórica sin requisitos adicionales.
  • La notificación para estos proyectos sólo tendría que ser hecha mediante rótulo.
  • El proceso para estos proyectos desplaza la Ley Sobre Política Pública Ambiental y la Ley de Procedimiento Administrativo Uniforme cuando haya algún conflicto entre éstas.
  • La revisión judicial tiene 20 días jurisdiccionales para presentarse y no se podrá paralizar la obra a menos que un tribunal lo ordene expresamente para prevenir un daño irreparable (Art. 12.40(f)).

Al momento de escribirse este artículo, la versión del Código aprobada por el Senado no dice que un data center será considerado como un Proyecto de Impacto Socioeconómico Prioritario. Los criterios para designar proyectos estratégicos los fijará el DDEC mediante reglamento. Sin embargo, ya que toda propuesta de generación, transmisión y distribución aprobada por el Negociado de Energía entraría en esta categoría. De convertirse esto en ley, habrá que monitorear si el componente de energía que apruebe el Negociado para un data center de IA entraría en esta categoría.

¿Quién aprobará los permisos?

Según nuestra lectura del proyecto de ley aprobado por el Senado, el Código centralizará los permisos en el gobierno central. Por ejemplo, los permisos en la zona marítimo-terrestre pasarían a la Oficina Central de Permisos (Art. 15.30). El Departamento de Recursos Naturales y Ambientales (“DRNA”) parece que perderá la facultad de conceder franquicias y licencias sobre aguas territoriales, terrenos sumergidos y la zona marítimo-terrestre, aunque conserva sus funciones de vigilancia y conservación. En zonas portuarias, la Oficina Central expediría el permiso con una recomendación de la Autoridad de los Puertos. Sin embargo, notamos un vacío aquí: el Proyecto no define quién autorizará el uso de terrenos sumergidos fuera de la zona marítimo-terrestre.

Los detalles se encontrarán en el Reglamento Único

La mayoría de los asuntos apremiantes cubiertos por este propuesto Código, por ejemplo, cuando se celebrarán vistas, que se considera un “impacto significativo”, y qué obras se excluyen de revisión ambiental, no están normadas aquí. El Código establece que la Junta de Planificación y Urbanismo preparará y adoptará el Reglamento Único, el cual tiene como propósito principal “proveer un cuerpo normativo uniforme, integrado y coherente de todas las disposiciones reglamentarias relacionadas a la evaluación, adjudicación y revisión de solicitudes de recomendaciones, consultas, permisos, autorizaciones, licencias y evaluaciones de cumplimiento ambiental para el desarrollo o uso de terrenos y la operación de negocios en Puerto Rico” (Art. 7.02). Hasta que éste se apruebe, el Reglamento Conjunto seguiría vigente (Art. 16.04).

La Junta tiene 60 días desde la vigencia del Código para empezar a redactar el Reglamento, 180 para prepararlo, y el reglamento entrará en vigor 30 días después de radicarse. Si se siguen estos términos, el Reglamento sería aprobado en 9 meses. 

El Código exige avisos en español e inglés sobre la adopción del Reglamento, 60 días para emitir comentarios y se celebrarán entre 1 y 3 vistas públicas obligatorias (Art. 7.07). Posteriormente, las enmiendas parciales requerirán 30 días de comentarios y las vistas serían discrecionales (Arts. 7.03 y 7.09). Una impugnación por defectos de procedimiento tiene 30 días desde la vigencia y no paralizará al reglamento (Art. 7.10).

En Resumen

¿Qué cambiaría con este proyecto? Al compararlo con las secciones del Reglamento Conjunto que explicamos en el artículo anterior, esto es lo que cambiaría en el proceso de Consulta de Ubicación para un proyecto como éste:

En resumen, el Código mejora un poco los procesos actuales en cuanto a transparencia: ofrece un registro público de solicitudes, intervención formal y notificaciones más completas. Si embargo, no cambia en nada la respuesta a la pregunta más importante, ya que las vistas públicas en una Consulta de Ubicación seguirían siendo discrecionales.

Quedan además dudas sobre cuánta participación se permitirá en los procesos ambientales, ya que ni la exclusión categórica ni la EA admiten terceros, y la DIA solo tendría vista pública “cuando aplique”. También quedan dudas sobre la vía rápida de los proyectos prioritarios, que desplaza la Ley sobre Política Pública Ambiental. 

Por último, el Código guarda silencio total sobre los data centers y otros proyectos similares de nuevas tecnologías. No exige a una compañía divulgar la ubicación antes de presentar un proyecto ni entregar reportes del uso de agua y energía, como ya los requieren algunos estados y la Unión Europea, como señalamos en nuestro post anterior. 

¿Y qué pasaría si el data center se piensa construir en tierra firme? El trámite podría ser distinto. El Código parte de una escala de intensidades de uso: si el uso propuesto no excede la intensidad máxima del catastro, el trámite es ministerial, sin Consulta de Ubicación ni vista pública (Arts. 12.03 a 12.05). El Senado describe que quien vaya a operar un uso permitido podrá presentar una declaración de uso en el Sistema Unificado, pagar el cargo y abrir el mismo día, sin inspección previa ni aprobación discrecional. El Código no dice nada sobre en qué nivel de la escala caería un data center.

Además, según nuestra lectura, una construcción bajo el Permiso de Construcción Consolidado cualifica automáticamente como exclusión categórica y se acredita mediante auto-certificación jurada, a menos que el predio esté en ciertas áreas como zonas inundables, humedales, áreas protegidas o la zona marítimo-terrestre (Arts. 12.34, 12.50 y 12.51). 

¿Qué puedes hacer?

Por el momento, este proyecto no es ley, así que, continúa monitoreándolo en las noticias, medios de comunicación y redes sociales. Sin embargo, de ser aprobado, tendrás oportunidad de expresarte formalmente cuando se abra el período de comentarios para el Reglamento Único. Si esto pasa, en cuanto a los proyectos de data centers de IA u otros proyectos similares, estas son preguntas que deberán hacerse:

  • ¿Quién es “colindante” cuando un proyecto está en las aguas del mar?
  • ¿Se ordenarán vistas públicas para proyectos de infraestructura marina o de alto consumo de energía o agua?
  • ¿Qué umbrales activan una DIA en vez de una EA?
  • ¿Se exigirá divulgar el consumo de agua y energía, como en la UE?

Esencia expuso cómo Puerto Rico puede aprobar megaproyectos costeros sin que el pueblo se entere.

¿Podría pasar lo mismo con un data center de Inteligencia Artificial instalado bajo el mar?

Es posible que hayas leído o escuchado de una compañía que planifica instalar un data center de Inteligencia Artificial (“IA”) alrededor de las playas de Puerto Rico y te dijiste “Esto no suena cierto. ¿Será verdad? La respuesta: sí, es cierto esto.

Por otro lado, quizás te estás enterando de esto por primera vez al leer este artículo, y esto te lleva a preguntarte “¿cómo es posible que no me haya enterado de esto? Con tanta ley que existe, ¿no hay una que obligue a publicar que se quiera hacer algo así en Puerto Rico? ¿No tendrían que hacer una vista pública que cubran en televisión y los periódicos para así yo verla y conocer más?”

Si te sorprende no haber escuchado de esto antes, no te preocupes. Esto se debe a que las leyes y reglamentos puertorriqueños no fueron diseñados para garantizar que te enteres de proyectos como éste antes de ser construidos. Un caso reciente donde vimos esto ocurrir fue en el del megaproyecto turístico Esencia en Cabo Rojo. En agosto de 2026, la Oficina de Gerencia de Permisos (“OGPe”) aprobó la Consulta de Ubicación de este proyecto, que consiste en una inversión de más de $2,000 millones de dólares en la costa suroeste de la isla, sin celebrar una nueva vista pública para esa etapa, pese a que más de 800 residentes solicitaron formalmente un proceso participativo. Los desarrolladores sostienen que ya cumplieron ese requisito en una fase anterior celebrada en marzo de 2025. Sus opositores señalan que, desde entonces, se añadieron 10 estudios nuevos al expediente que nunca pasaron por escrutinio público. Ante una oposición generalizada a este proyecto, el Senado de Puerto Rico anunció que investigará el proyecto en vistas propias, con la primera celebrándose el pasado 1 de septiembre. Si hay tanta controversia con un proyecto de hoteles y residencias sobre tierra, ¿qué pasaría si algún día alguien intentara instalar, de forma prácticamente invisible, data centers de IA bajo nuestras playas?

Hoy, Farrant Te Explica este propuesto proyecto, quién lo propuso, cómo podría obtener permisos para operar bajo las leyes de Puerto Rico, cómo se comparan éstas con los Estados Unidos y la Unión Europea, te resumimos la conversación que tuvimos con los líderes de una empresa que ha considerado hacer esto, y te contamos porque esto te debe importar aunque vivas en la cima de una de nuestras montañas y nunca vayas a la playa o un muelle.

I. ¿Quién es Seabase y qué quieren hacer?

Según nuestra conversación con Reilly McAdams, co-fundador y Chief Executive Officer (“CEO”) de Seabase, esta es una compañía incorporada en Delaware como Seabase Industries Inc., con sede en Houston, que construye unidades de computación modulares y encapsuladas diseñadas para estar en o cerca del fondo marino, cerca de puertos y enfriadas con agua de mar en vez de agua dulce o sistemas de aire acondicionado que gastan mucha electricidad.  Previo a su inscripción en Delaware, la compañía registró 2 corporaciones en Puerto Rico el 6 de marzo de 2026, Seabase Network LLC, con número de registro 575350, y Seabase Industries LLC, con número de registro 575352.

Ambas compañías puertorriqueñas tienen como personas autorizadas a Reilly McAdams (co-fundador y CEO de Seabase según su página web), Oliver Willcox (co-fundador y presidente) y Ashby Green (CFO).

En su página web, Seabase expresa que se diferencia de la competencia porque su arquitectura separa una plataforma submarina de larga vida de equipo computacional de corta vida, que puede ser reemplazado durante el tiempo. Ellos venden además un producto, llamado Nori, creado para permitirle a sus clientes reservar y monitorear las capacidades de su equipo.

Los co-fundadores de Seabase, el CEO Reilly McAdams y el COO Ollie Willcox, fueron entrevistados por News Is My Businessen mayo de 2026. En ese momento, contaron que la compañía estaba evaluando lugares en Ponce, San Juan y en la costa este de Puerto Rico, y  buscando alianzas con universidades y agencias de gobierno, nombrando al Recinto de Mayagüez de la Universidad de Puerto Rico en esa entrevista. McAdams señaló además que Puerto Rico depende demasiado de la infraestructura en Estados Unidos, destacando que la mayoría de la capacidad computacional y tecnológica en la isla se encuentra en Miami, y que esto hace a la isla muy vulnerable si algún día se daña una conexión de fibra óptica en el fondo del mar.

Durante nuestras conversaciones con Seabase en septiembre de 2026, éstos nos informaron que, aunque han evaluado sitios potenciales en Puerto Rico, no han seleccionado un lugar específico ni han adelantado un proyecto. Asimismo, nos dijeron que, aunque Puerto Rico “continua siendo un mercado atractivo, no se encuentra actualmente entre nuestras localidades principales de implementación a corto plazo”, y que su trabajo actual está explorando oportunidades en los Estados Unidos continentales e internacionalmente, incluyendo otras localizaciones en el Caribe.

A nivel técnico, los materiales públicos de Seabase describen sus “pods” como unidades que corren entre 0.5 to 3 megawatts cada una, en contenedores estándares, los cuales se agregan en clusters de 10 a 20 megavatios, utilizando sistemas cerrados de enfriamiento con agua de mar en vez de sistemas evaporativos con agua dulce. Según nos contó MacAdams, sus sistemas submarinos usan un circuito cerrado interno de enfriamiento que libera el calor al ambiente marino circundante, evitando el enfriamiento evaporativo y el consumo de agua dulce comunes en muchos data centers convencionales. Esta arquitectura, según nos indicó, podría reducir la necesidad de terrenos al ubicar la infraestructura computacional en el mar o dentro de entornos marinos y portuarios ya existentes.

Al preguntársele si este sistema que libera calor al ambiente marino generaría algún impacto, nos respondió que se trata de un proceso pasivo, en el que un circuito cerrado interno transfiere el calor a través de intercambiadores de calor externos, en vez de bombear agua de mar a través del data center. Añadió que modelarían la pluma térmica para cada sitio, diseñando el proyecto de manera que los cambios localizados de temperatura se mantengan mínimos, y que planean ser completamente transparentes con el público en cuanto a sus datos e impacto marino.

Le preguntamos además a Seabase si un proyecto como éste afectaría el acceso público a las playas, y si impediría el uso de botes alrededor. Nos respondieron que no esperan que sus proyectos restrinjan el acceso a las playas, ni la pesca ni el uso de embarcaciones, ya que buscarían lugares con suficiente profundidad y distancia de la costa para mantenerse alejados de playas, áreas de natación, rutas de navegación recreativa, canales de navegación y zonas de pesca importantes. Su meta, nos dijeron, es que las personas que usan las playas y botes cerda de estos pods prácticamente no sepan que la infraestructura se encuentra ahí.

En resumen, al día de hoy, Seabase no tienen en sus planes inmediatos construir un data center en nuestras playas. Sin embargo, esto no impide que, en el futuro, Seabase u otra compañía expresen interés en construir un data center en nuestras aguas. Así que, a continuación, Farrant Te Explica cómo nuestras leyes y reglamentos atenderían esta situación.

II. ¿Qué leyes y Reglamentos puertorriqueños regulan la construcción de un data center de IA en nuestras playas?

Al momento de escribirse este artículo, Puerto Rico no tiene ninguna ley que regula la construcción de data centers de IA en nuestras tierras o aguas. No obstante, en caso que Seabase u otra compañía quiera hoy comenzar el proceso de obtener permisos para construir un data center en el mar, existen 3 marcos legales que podrían aplicar. Hoy, Farrant Te Explica cada uno de estos.

Marco 1: Revisión Ambiental (Ley 416-2004 y procesos de OGPe/JCA).

La ley más importante en Puerto Rico en materia ambiental es la Ley sobre Política Pública Ambiental (Ley 416-2004). La misma requiere a las agencias públicas a evaluar impactos ambientales significativos que puedan causar los proyectos previo a otorgar permisos.  Estos permisos suelen ser dados por la Oficina de Gerencia de Permisos (“OGPe”) trabajando con la Junta de Calidad Ambiental (“JCA”), los cuales evalúan proyectos al amparo del Reglamento Conjunto para la Evaluación y Expedición de Permisos Relacionados al Desarrollo, Uso de Terrenos y Operación de Negocios (Reglamento 9473 de la Junta de Planificación, aprobado el 16 de junio de 2023) (“Reglamento Conjunto”), y el Reglamento para el Proceso de Evaluación Ambiental de la JCA (Reglamento 8858 del 23 de noviembre de 2016).

Bajo esta ley y reglamentos, los desarrolladores presentan una Evaluación Ambiental (“EA”) para sus proyectos o, cuando el impacto ambiental puede ser significativo, presentan una Declaración de Impacto Ambiental (“DIA”). Las reglas 2.2.4(c ) y 3.1.3.3(a)(1) del Reglamento Conjunto establecen que cualquier asunto discrecional que requiera celebrar una vista pública o que requiera presentar una DIA, será adjudicada en 180 días. Este mecanismo, una vez activado, garantizaría una audiencia pública y un período de tiempo definido. Sin embargo, lo importante es determinar si un proyecto requiere una EA, una DIA o si el proyecto no necesita ninguna.

Marco 2: Consulta de Ubicación.

Un pod como el de Seabase, el cual contiene un data center de IA colocado bajo el mar, no cabe bajo ninguna categoría de zonificación existente. Para casos como éste, la Regla 2.2.3.2 (d) del Reglamento Conjunto crea un proceso discrecional de “Consulta de Ubicación” precisamente para usos que, por su naturaleza o intensidad, necesitan ser ubicados en un lugar especifico que los mapas de zonificación existentes no anticipan. Esta es la categoría que el Reglamento Conjunto usa para proyectos innovadores, y fue el que se usó para aprobar el proyecto de Esencia hace unos meses. Esto es importante porque estos procesos de Consulta tienen criterios de divulgación al pública mucho más reducidos que los que tiene el proceso de DIA, en particular:

  1. La notificación sólo se necesita hacer a los colindantes del proyecto, por correo certificado, en un período no mayor de 5 días luego de la radicación de la solicitud (Regla 2.2.2.2 (a)).
  2. Es discrecional la celebración de una vista pública, según la Regla 2.2.3.19. Esta Regla dice que sólo se hará vista pública “en aquellos casos que la reglamentación vigente así lo requiera o para aquellos casos en que la Junta Adjudicativa lo estime pertinente, en la cual se permitirá la participación a cualquier persona interesada y que solicite expresarse sobre el asunto en consideración.”
  3. Las personas con standing (legitimación) para retar o intervenir en una determinación es limitada. La Regla 2.2.3.4(a) únicamente legitima al dueño de la propiedad, optante o arrendatario de la propiedad por sí o a través de su representante autorizado en casos de proyectos privados, o al Jefe de la Agencia o su representante autorizado en casos de un proyecto público. Asimismo, el inciso (c) de esta Regla establece que la revocación de una consulta podrá ser promovida por la Junta Adjudicativa “a iniciativa propia o a solicitud de persona con interés legítimo”, término que no es definido con claridad.

En conclusión: si un proyecto es aprobado a través de una Consulta de Ubicación en vez de una DIA, los mecanismos de vistas públicas que muchas personas piensan que existen simplemente nunca se activarían aquí.

Marco Tres: Zona Portuaria – Autoridad de los Puertos.

La Regla 7.3.4 del Reglamento Conjunto dispone que, dentro de una Zona Portuaria (“ZP”), la Autoridad de los Puertos (“Puertos”) – y no el DRNA – es la encargada de controlar y administrar los puertos de Puerto Rico, las aguas navegables que forman parte de zonas portuarias, los muelles de propiedad pública, los terrenos sumergidos bajos los muelles, las zonas marítimas terrestres comprendidas en toda zona portuaria, y todos los edificios y estructuras enclavadas en la misma que sean propiedad o estén bajo el dominio de Puerto Rico. Por eso, seguramente es que Seabase le dijo a News Is My Business que estaba en comunicaciones con la Autoridad de los Puertos. Fuera de una ZP, aplicarían los procesos de permisos para zonas marítimo-terrestres del DRNA, bajo la Ley de Muelles y Puertos de Puerto Rico de 1968, Ley 151-1968.  En estos casos, el DRNA puede permitir usos dependientes de agua como muelles y plataformas pero no puede convertir tierras sumergidas en propiedad privada.

Además de estos 3 marcos, un proyecto como éste podría estar cubierto bajo las siguientes leyes y procesos:

  1. Conexiones Energéticas (“Energy Interconnection”).

Una facilidad de 10-20 megavatios como las descritas por Seabase necesitan conectarse a la red eléctrica, por consiguiente, caería bajo la jurisdicción del Negociado de Energía (“PREB”) y cualquier otra agencia que maneje el estudio de conexión. Además, contrario a una lista creciente de estados, Puerto Rico no tiene una tarifa específica para grandes cargas ni una ley u ordenanza que regule específicamente los data centers.

Sobre este punto, Seabase nos dijo que su meta es de no “añadir una nueva gran carga a una red que ya está bastante limitada. Estamos evaluando modelos que parean infraestructura computacional con generación de nueva energía y almacenamiento de baterías, para potencialmente apoyar la resiliencia y flexibilidad de la red cuando el sistema local lo permita”.

  1. Decretos de Incentivos Contributivos bajo la Ley 60.

El Código de Incentivos de Puerto Rico, Ley 60-2019, consolida los programas de incentivos bajo la Oficina de Incentivos Para Negocios, los cuales cubren proyectos de infraestructura y energía renovable, además de revisar los beneficios por trabajar en una Zona de Oportunidad federal (“Opportunity Zone”). Para obtener un decreto que apruebe un incentivo, la entidad necesita solicitarlo al Departamento de Desarrollo Económico y Comercio (“DDEC”), y este proceso no requiere un proceso de vista pública.

Se le preguntó a Seabase si alguna de sus entidades puertorriqueñas tenía o había solicitado un decreto de incentivo contributivo bajo la Ley 60. Su CEO, Reilly McAdams, nos respondió que ninguna de sus entidades tiene un decreto o una solicitud pendiente de aprobación bajo la Ley 60 o cualquier otro incentivo contributivo, afirmando que las entidades son “entidades corporativas ordinarias”.

  1. Infraestructura Dedicada a las Telecomunicaciones

La Regla 9.11 del Reglamento Conjunto norma los proyectos de construcción, instalación y ubicación de torres e instalaciones de telecomunicaciones a través del Negociado de Telecomunicaciones (“NET”), entidad adscrita a la Junta Reglamentadora de Servicio Público de Puerto Rico (“JRSP”). La Regla 9.11.11 establece que se requerirán vistas publicas en casos de solicitudes de variaciones para la instalación o ubicación de torres y de instalaciones de telecomunicaciones cuando éstas respondan a exigencias tecnológicas, de emergencia o de seguridad pública.

Aunque esto es un estándar mucho más fuerte que el de la Consulta de Ubicación, aplica a pocos casos. En caso de que la fibra óptica o infraestructura de conexión de Seabase u otra compañía requiera una variación, éste sería el único proceso bajo el Reglamento Conjunto donde se requeriría que la entidad publique un anuncio en el periódico y participe en una vista pública.

  1. Reglamentos y Permisos Federales

Toda vez que la instalación de un data center en el mar sería hecho en aguas navegables de los Estados Unidos, seguramente será necesario obtener un permiso bajo la Sección 10 del Rivers and Harbors Act, 33 U.S.C. 403, y un permiso del Cuerpo de Ingenieros de los Estados Unidos bajo la sección 404 del Clean Water Act, además de requerir una licencia para enterrar cables submarinos si conexiones de fibra se colocan en aguas de jurisdicción federal.

III. ¿Cómo compara el marco jurídico puertorriqueño con el de Estados Unidos y la Unión Europea?

  1. Frente a Estados Unidos – El proceso de revisión ambiental de Puerto Rico sigue muy de cerca al National Environmental Policy Act (“NEPA”) , al punto que los reglamentos puertorriqueños atienden situaciones en las que una agencia local co-dirige un proceso de revisión ambiental con una contraparte federal bajo NEPA.

Por otro lado, durante el 2026, un número de legislaturas estatales han pasado leyes para obligar a las compañías que desean construir data centers de IA a divulgar sus planes antes de comenzar las construcciones. Por ejemplo, Nueva Jersey ahora obliga a los operadores de data centers a divulgar públicamente cuánta agua y energía consumen (S3379/A4096), además de haber aprobado recientemente la “Data Center Fair Share Act (A5462)”, que establece tarifas de electricidad separadas para los data centers.

A nivel federal, la representante LaMonica McIver (D-NJ) presentó el AI Data Center Site Selection Transparency Act of 2026, el cual requeriría a los desarrolladores de data centers a divulgar la ubicación de locales seleccionados a oficiales electos y al públicos al menos 180 días antes de tomar un paso de desarrollo definitivo. Este proyecto de ley se radicó porque esta industria ha estado firmando acuerdos de confidencialidad (“nondisclosure agreements” o “NDAs”) con oficiales públicos para prohibirles que hablen de estos proyectos o su impacto potencial. Hay un número de estados que se han movido para prohibir las firmas de NDAs entre funcionarios públicos y desarrolladores.

En Puerto Rico, nadie ha prohibido que el gobierno firme NDAs con estas entidades y no hemos encontrado un proyecto de ley que intente regular los Data Centers.

  1. Frente la Unión Europea (“UE”). La UE regula esto completamente diferente: requieren informes de sostenibilidad continuos, en vez de una divulgación antes de comenzar el proyecto. Bajo el Artículo 12 de la Directiva de Eficiencia Energética, los estados miembros de la UE deben asegurarse que los data centers con al menos 500 kilovatios de potencia de tecnología de información instalada hagan pública toda su información de desempeño energético, y la publiquen en una base de datos compartida a través de toda la UE que cubre aproximadamente 24 indicadores. La Comisión Europea espera finalizar un proceso de clasificación y etiquetado (“labeling”) para toda la UE. Los clusters de 10-20 MW que Seabase proyecta usar, según su página web, sobrepasan el mínimo de 500Kw de la UE. Por consiguiente, si su proyecto se construyera en Europa, tendrían que reportar al público, cada año, cuánta agua y energía renovable usan, y cual es su efectividad energética. En Puerto Rico, bajo las leyes existentes, no tendrían que divulgar esto.

En resumen: Puerto Rico regula si un proyecto es aprobado. Sin embargo, para un proyecto innovador como éste, pareciera que el mismo podría ser aprobado a través de un marco legal que contempla vistas públicas discrecionales y que le da legitimación limitada al público para oponerse. Por otro lado, los estados están enfocados en regular si se le notifican estos proyectos al público previo a su construcción. Finalmente, la UE regula si el público necesita seguir siendo informado del proyecto de forma indefinida. El marco legal de Puerto Rico, al compararse, es mucho más débil al inicio del proyecto comparado con estas jurisdicciones, y guarda silencio sobre todo lo demás.

IV. ¿Por qué debe importarte esto?

Porque, aunque el CEO de Seabase nos contó que Puerto Rico no se encuentra actualmente en sus prioridades a corto plazo, debes estar consciente de al menos 3 aspectos de esta historia, independientemente de lo que haga Seabase u otra compañía en el futuro.

  1. El precedente que se establecerá. Seabase y su liderato nos proveyeron respuestas detalladas y específicas sobre la lógica de colocación de sus unidades, el modelaje de su pluma térmica, y su interés en no impactar la flora y fauna marina. Este es el tipo de comunicación e intercambio que muchas compañías no ofrecen a menos que sean obligadas a hacerlo por una autoridad gubernamental o judicial. Este intercambio fue un buen ejemplo de cómo esperaríamos que Seabase se comporte si decide retomar este proyecto en Puerto Rico. Sin embargo, su buena fe y disposición no es un sustituto al hecho de que este intercambio debería ser uno requerido por ley, y la próxima compañía que quiera venir a Puerto Rico a proponer la construcción de un data center de IA debajo del agua podría no ser tan receptiva al diálogo como ellos. El vacío actual en el Reglamento Conjunto, el cual permite estas consultas de ubicación dentro de un proceso que no garantiza vistas públicas, no se llena simplemente con la buena disposición de una compañía respondiendo a nuestras preguntas. Asimismo, sería vital asegurarse que existe el marco legal para corroborar que una empresa cumpla con todo lo que promete.
  2. El uso de energía y agua. La descripción que nos dio Seabase sobre su enfoque de trabajo – sistemas pasivos y de enfriamiento de circuito cerrado que evitan bombear agua de mar a través del sistema, además de su interés en generar y almacenar su propia energía en vez se ser una carga adicional a nuestra red actual –  suena como un modelo muy diferente al que usan los data centers convencionales, y uno que podría ser mucho mas responsable y sostenible si logra implementarse. Sin embargo, la propuesta de Seabase es, por ahora, una simple propuesta teórica, ya que no se han escogido lugares o completado un análisis ambiental. Por ende, los retos que presenta construir data centers en Puerto Rico sobre nuestros frágiles y colapsados sistemas de agua son reales. De hecho, escribo estas líneas durante la cuarta noche consecutiva sin agua en mi casa. Estos retos aplican a cualquier proyecto que Seabase o cualquier otra compañía quiera implementar aquí.
  3. La necesidad urgente de exigir transparencia. Nuestro intercambio con Seabase fue un pequeño ejemplo que muestra la necesidad de formalizar procesos de transparencia en las etapas de pre-desarrollo de un proyecto. Seabase respondió a todas nuestras preguntas simplemente porque quisieron conversar con nosotros, y no porque una ley se lo requiriera. Sin embargo, una futura compañía que quiera establecerse en Puerto Rico con el mismo fin podría no tener la misma buena disposición que tuvo Seabase. Por consiguiente, se hace necesario en Puerto Rico crear leyes similares a las que están pasando varios estados requiriendo la divulgación anticipada de este tipo de proyectos, mientras se espera que el Congreso algún día apruebe el AI Data Center Site Selection Transparency Act o una ley similar.

V. Mejores Prácticas y Recomendaciones para Compañías y el Público

  • Publicar modelos ambientales específicos a una posible ubicación antes de ser requerido por ley. Durante nuestra conversación, Seabase nos proveyó muchos detalles técnicos de sus proyectos y contestó todas nuestras preguntas. Esto es precisamente el tipo de divulgación proactiva que debería ser el estándar en la industria, y no la excepción. Los proponentes que hacen esto generan confianza en el público, ya que lo hacen antes que la ley les obligue.
  • Establecer procesos amplios de vistas públicas. Se debe legislar para prohibir que un desarrollador auto-seleccione procesos que no requiera vistas públicas para casos como éste. Los gestos de buena fe de los líderes de una compañía no son ley, y ciertamente pueden cambiar una vez comience un proceso de obtención de permisos. En un caso como éste, en el que hay preguntas reales sobre el impacto que un proyecto de este tipo pueda traer a nuestras ciudadanía, costas, flora y fauna marina, y nuestros sistemas de agua y luz, se necesitan celebrar procesos de vistas públicas independientemente de la buena fe del proponente.
  • Publicar voluntariamente proyecciones de uso de agua y energía, antes que una autoridad lo exija. Los litigios en Estados Unidos sobre data centers frecuentan ser por su uso de NDAs que les permiten no divulgar información como esta.
  • Publicar los procesos de revisión de proyectos que estén llevando OGPe, DRNA, y Puertos, para que el público no tenga que averiguar cuál de estas agencias es la que tiene jurisdicción sobre cada parte del proyecto.
  • Crear planes de comunicación e involucramiento con la comunidad. En estos tiempos, las personas alrededor del mundo tienen escepticismo sobre los riesgos de la IA y cómo afectará sus vidas. Proponentes de proyectos como el de Seabase necesitan ser transparentes en sus intenciones y planes, y establecer y publicar objetivos con métricas que el público pueda verificar y seguir.
  • Fiscalizar al gobierno. Necesitamos asegurarnos que el gobierno cumpla con sus propias leyes, celebre vistas públicas, promueva la transparencia, y permita que personas y entidades tengan legitimación para intervenir en los procesos administrativos y judiciales.

VI. Conclusión

Le agradecemos grandemente a Seabird por haber respondido a todas nuestras preguntas de forma mucho más rápida y concreta que muchas otras compañías. Nuestros intercambios con ellos nos llevaron a conocer una compañía que consideró seriamente la isla para este proyecto, la evaluó, creó 2 corporaciones puertorriqueñas, generó interés local, pero luego concluyó que Puerto Rico no está entre sus prioridades a corto plazo, aunque dejan la puerta abierta para regresar.

Una vez llegue ese día, veremos como el ordenamiento de Puerto Rico lo analiza y revisa. El proceso de DIAs garantizaría una vista pública donde la ciudadanía puede expresarse. Sin embargo, el proceso de Consulta de Ubicación, el cual podría ser escogido para autorizar un proyecto tan significativo como éste, no exige celebrar vistas públicas. La transparencia mostrada por Seabase en nuestras conversaciones no elimina la necesidad de asegurarnos que nuestras leyes aseguren esta transparencia, porque no queremos vivir en un lugar donde existan leyes que garanticen la oscuridad.

¿Qué te pareció este artículo? ¿Debe Puerto Rico permitir los data centers de IA? ¿Crees que este desarrollo deba seguir el proceso de DIA o el de Consulta de Ubicación? Déjanos tus comentarios.

¿Puedo Ser Acusado de Discrimen en el Trabajo bajo las leyes de Puerto Rico por Haber Usado ChatGPT y Claude para revisar résumés?

En nuestro artículo de hace 2 semanas, hablamos sobre como usar IA para filtrar résumés te expone a leyes que prohiben el discrimen en el trabajo. Hoy queremos enfocarnos en los riesgos que tienes si operas en Puerto Rico bajo una ley que seguramente nadie te mencionará cuando evalúas una herramienta de “screening” automatizado: la Ley Núm. 100 de 30 de junio de 1959, nuestra ley contra el discrimen en el empleo, la cual aplica aunque su texto no contenga la palabra “algoritmo” — y añade consecuencias que las leyes federales y la Unión Europea no tienen.

¿Qué dice la Ley 100 Actualmente?

Antes del 2017, la Ley 100 tenía una herramienta poderosa a favor del empleado, ya que establecía que una acción adversa — como no contratar, no ascender, despedir a una persona— tomada sin justa causa, se presumía discriminatoria. Una vez el empleado activaba esa presunción, la carga pasaba casi por completo al patrono, quien tenía que probar afirmativamente que no hubo discrimen.

Eso cambió con la Ley de Transformación y Flexibilidad Laboral (Ley 4 de 2017), que eliminó esa presunción para alinear a Puerto Rico con el estándar federal conocido como McDonnell Douglas. Hoy, un reclamo bajo la Ley 100 funciona de forma muy parecida a uno federal: el empleado debe establecer un caso preliminar (que pertenece a una clase protegida, que estaba cualificado, que hubo una acción adversa, y que otros en circunstancias similares fuera de esa clase protegida fueron tratados mejor). Si lo logra, el patrono debe articular una razón legítima y no discriminatoria para la decisión. Si el patrono hace esto, la carga vuelve al empleado, quien debe probar que esa razón fue un pretexto.

En resumen, hoy día, la carga de persuadir al tribunal que hubo discrimen recae más sobre el empleado que el patrono.

No obstante, la IA introduce un problema real para un patrono incluso bajo este estándar más favorable. El segundo paso del análisis te exige poder articular una razón legítima para el rechazo. Si tu único proceso fue subir résumés a una herramienta de terceros y dejar que un algoritmo los descartara, ¿cuál es tu razón legítima para rechazarlos? “El sistema le dio menor puntaje” no siempre basta, sobre todo si el candidato puede mostrar —con estadísticas, como permite la teoría de impacto discriminatorio bajo Título VII— que el patrón de rechazos de la herramienta, como por ejemplo, que descarta mayormente mujeres para una posición, correlaciona con una categoría protegida. En ese escenario, la falta de explicación se convierte en la evidencia de pretexto que el empleado necesita para prevalecer

Por otro lado, aunque la carga de la prueba ya no está automáticamente en contra del patrono, la Ley 100 sigue teniendo algo que el Título VII no tiene: penalidades más severas, que veremos a continuación.

¿Cuáles son las penalidades bajo la Ley 100?

La Ley 100 impone responsabilidad civil al patrono por el doble de los daños causados (o entre $500 y $2,000 si los daños no se pueden determinar). Además, la conducta discriminatoria podría constituir un delito menos grave, castigado con multa de hasta $5,000 o cárcel de hasta 90 días, o ambas penas. Nada de esto existe bajo ninguna ley antidiscrimen federal. Por consiguiente, aunque es inusual que estos casos se persigan criminalmente, el usar IA para revisar résumés podría técnicamente exponerte a responsabilidad penal en Puerto Rico. Es una consecuencia que muchos patronos no conocen o anticipan.

¿Cómo está regulado este tema en otras jurisdicciones?

  • Estados Unidos: no existe una ley federal sobre IA en el empleo. En su lugar, hay un mosaico de leyes locales y estatales tales como la Local Law 144 de la ciudad de Nueva York que impone auditorías de sesgo (bias audits), la notificación a un candidato cuando sea entrevistado en video por IA en Illinois, las evaluaciones de riesgo de Colorado, además de las leyes federales antidiscrimen ya existentes (Título VII, ADEA, ADA) por la EEOC, las cuales se interpretan bajo el estándar del caso del Tribunal Supremo de Estados Unidos McDonnell Douglas. Todas estas leyes y ordenanzas pueden reducirse a que permiten el uso de herramientas de IA, pero prepárate para justificarla si alguien la cuestiona y además, conoce los requisitos específicos de cumplimiento que existan en el estado donde trabajas o evaluas candidatos.
  • Unión Europea: si tu empresa trabaja con candidatos o empleados en la Unión Europea, o si simplemente quieres entender hacia dónde va la regulación de IA en el mundo, vale la pena mirar el EU AI Act (Reglamento (UE) 2024/1689), que ya está en vigor, y es probablemente el cuerpo legal más comprensivo en el mundo actualmente sobre la Inteligencia Artificial. El EU AI Act clasifica las herramientas de IA usadas para reclutamiento y selección de personal —incluyendo filtrar solicitudes de empleo y evaluar candidatos— como sistemas de “alto riesgo.” Eso significa que, antes de poder usarse legalmente, la herramienta debe pasar por una evaluación de conformidad, tener documentación técnica, sistemas de gestión de riesgo, mecanismos de supervisión humana, y registrarlos en una base de datos de la UE. Además, el patrono tiene la obligación específica de informar a los trabajadores y sus representantes de la existencia de este sistema antes de utilizarlo. En la Unión Europea, contrario a Puerto Rico y Estados Unidos, un patrono necesita demostrar que su plataforma es segura antes de usarla.

Las diferencias en enfoque son significativas.  Mientras en la UE se certifica la herramienta previo a su uso, en Puerto Rico y Estados Unidos no se exige nada por adelantado, pero se imponen consecuencias legales si la herramienta produce un resultado discriminatorio. 

¿Por Qué Debe Importarte Esto?

Porque usar un IA que discrimina contra candidatos te pone en riesgo de pagar indemnización y, si estás en Puerto Rico, te pone en riesgo de ir a la cárcel.

Piénsalo en términos prácticos: si tu herramienta de IA rechaza desproporcionadamente a candidatos de cierta edad u origen, y un candidato logra probar pretexto —por ejemplo, mostrando que no pudiste explicar de forma coherente por qué el sistema lo descartó, enfrentas la posibilidad de indemnizar a las personas afectadas por el algoritmo y de ser responsable penalmente por haberlo usado. Para un negocio pequeño o una clínica, esa es una exposición realmente significativa que va más allá de lo que anticiparías si sólo miras las leyes federales como referencia o si descansas en que ChatGPT fue hecho “sin intención de discriminar” o porque usaste la herramienta de IA de “buena fe”.

¿Cómo Puedo Cumplir con la Ley?

  1. Ten siempre una razón articulable para cada rechazo. No basta con “el sistema le dio menor puntaje a X candidato.” Debes poder explicar, en términos concretos y relacionados con las cualificaciones del puesto, por qué un candidato no avanzó en el proceso de entrevistas.
  2. Exígele documentación al vendedor. Pregunta si la herramienta ha sido auditada por sesgo, con qué frecuencia, y si te proveen esa documentación. Esa evidencia es lo que te permite cumplir con el paso de “articular una razón legítima” si te cuestionan.
  3. Guarda un registro de cada decisión. Qué datos entraron, qué puntaje o resultado produjo el sistema, y qué revisión humana se hizo antes de las decisiones finales. Esa bitácora es tu evidencia si algún día tienes que defender el proceso.
  4. Notifica a los candidatos que usas IA en el proceso. Es buena práctica en Puerto Rico y ya es obligatorio bajo el EU AI Act si tienes candidatos o empleados en Europa.
  5. Haz una evaluación de riesgo antes de adoptar la herramienta, no después de la primera querella. Pregúntate: ¿con qué datos fue entrenada? ¿Qué categorías protegidas podría estar afectando indirectamente? Recuerda que la Ley 100 protege, entre otras, edad, raza, color, sexo, orientación sexual, identidad de género, origen social o nacional, condición social, afiliación política, ideas políticas o religiosas, ser víctima de violencia doméstica/agresión sexual/acecho, condición de veterano, estado civil, y hasta ciertos peinados y texturas de cabello asociadas a identidades raciales u orígenes nacionales particulares.
  6. Revisa el contrato con el vendedor. ¿Quién asume responsabilidad si la herramienta produce un resultado discriminatorio? Negocia esa cláusula si puedes.

En Resumen

Desde la reforma laboral de 2017, la Ley 100 ya no te coloca en una posición probatoria peor que la ley federal — el análisis hoy se parece bastante al estándar de McDonnell Douglas. Lo que sí distingue a Puerto Rico es lo que pasa si pierdes: daños dobles automáticos y la posibilidad de responsabilidad penal, ninguno de los cuales existe bajo el Título VII. Recuerda además que si no puedes explicar por qué tu herramienta rechazó a un candidato, podrías estar violando la ley. Finalmente, recuerda que necesitas mantener documentados tus procesos, asegurarte que sean supervisados por personas, y que puedas explicar y justificar cada decisión. Conoce y formaliza tus procesos antes que necesites hacerlo frente a una agencia gubernamental o un tribunal.

¿Piensas que tus procesos de contratación actuales con IA te dejarían expuesto a responsabilidad legal bajo la Ley 100 si un candidato presenta una querella hoy, o simplemente quieres asegurarte de tener procesos que cumplen con la ley? Conversemos. Agenda una consulta aquí.

Sobre el Autor

Jaime Farrant es un abogado admitido para ejercer derecho en Puerto Rico, Nueva York, Maryland y el Distrito de Columbia. La práctica legal en cualquier otro estado está limitada al derecho de inmigración.

MATERIAL PUBLICITARIO. Este artículo constituye publicidad tal como se define en las reglas de conducta profesional en vigor en Nueva York (22 NYCRR 1200.7.1 y 1200.7.3), Maryland (Rule 19-307.1 y 19-307.2) y el Distrito de Columbia (D.C. Rules of Professional Conduct 7.1), así como en las Reglas de Conducta Profesional de Puerto Rico (Reglas 7.1-7.3). No constituye inducción a clientes potenciales conocidos que necesiten servicios legales en un asunto particular. Por el contrario, se trata de información general dirigida al público sobre el ejercicio del derecho y los servicios legales disponibles. Ninguna relación abogado-cliente se crea por la lectura de este articulo o por contactar al autor.

¿Qué Pasaría Si el Sistema de Inteligencia Artificial de Tu Proveedor Decide Hackear a Otra Persona?

¿Alguna vez has pensado en lo que le podría pasar a tu negocio si el sistema de inteligencia artificial de tu proveedor decide, por su cuenta, entrar sin autorización a los servidores de otra empresa? Si no lo has pensado, quizás sea buen momento para hacerlo, porque las consecuencias para tu negocio podrían ser severas. Si tu negocio está regulado por HIPAA, una violación de esta ley podría traerte una multa civil de hasta $2,190,294 por categoría de violación, por año, en el nivel más alto de culpabilidad. Incluso un negocio que no hizo nada mal, donde el sistema de IA de un proveedor actuó completamente por su cuenta, podría enfrentar una multa de un nivel menor, una investigación del Departamento de Salud (“HHS”) de Estados Unidos, costos de notificación de incidentes de seguridad, y daño reputacional, por algo que nunca causó y que no pudo haber previsto.

Esta posibilidad ya no es hipotética. El 21 de julio de 2026, OpenAI publicó en su página web un aviso donde asumió responsabilidad por un ciberataque a Hugging Face, una plataforma ampliamente usada para alojar modelos de inteligencia artificial y colaboración en aprendizaje automático. Según OpenAI, una combinación de sus modelos —incluyendo uno disponible al público y otro más avanzado aún no lanzado, ambos operando con restricciones de seguridad reducidas para una evaluación interna de ciberseguridad— logró escapar de su entorno de prueba aislado explotando una falla previamente desconocida en una herramienta de software interna, obtuvo acceso a internet abierto, y luego utilizó credenciales robadas y otra vulnerabilidad desconocida para lograr ejecución remota de código en los servidores de producción de Hugging Face. Su objetivo, según OpenAI, era limitado pero revelador: los modelos intentaban obtener las respuestas correctas de la prueba de evaluación en la que estaban siendo calificados. Hugging Face ya había detectado la intrusión durante un fin de semana de actividad automatizada, la reportó a las autoridades, y comenzó su propia contención antes de siquiera saber que OpenAI era responsable.

Ambas empresas han calificado esto como un momento decisivo para la ciberseguridad. Para un pequeño negocio, consultorio médico, u oficina profesional que depende de proveedores externos —incluyendo herramientas de IA— para almacenar, procesar, o transmitir información sensible, esto también debe ser una llamada de atención sobre un tipo de riesgo que la mayoría de los contratos con proveedores nunca contemplaron: el agente de IA que actúa por su propia cuenta.

¿Por Qué el Comportamiento de la IA de Tu Proveedor Podría Convertirse en Tu Problema?

La mayoría de las leyes de privacidad y seguridad de datos que aplican a pequeños negocios no distinguen entre una filtración causada por un hacker humano y una causada por un sistema autónomo. Si tu práctica o negocio utiliza un asociado de negocio de una entidad cubierta, un proveedor de servicios en la nube, o cualquier tercero que tenga acceso a información personal o de salud, generalmente eres responsable legalmente de:

  • Evaluar las prácticas de seguridad de ese proveedor antes de firmar un contrato (debida diligencia).
  • Contar con las protecciones contractuales adecuadas, como un Acuerdo de Asociado de Negocio (BAA, por sus siglas en inglés) bajo HIPAA para consultorios médicos, o términos comparables de procesamiento y seguridad de datos para cualquier negocio que maneje información personal.
  • Notificar a las personas afectadas, y en algunos casos a los reguladores, si el sistema de ese proveedor se ve comprometido y tus datos están involucrados.

Bajo HIPAA, los asociados de negocio de una entidad cubierta están contractual y legalmente obligados a proteger la información de salud protegida (PHI, por sus siglas en inglés), y una filtración a nivel del proveedor puede generar obligaciones de notificación para la entidad cubierta misma, aunque haya sido el sistema del proveedor —y no el del consultorio médico— el que falló. Fuera del sector de salud, la mayoría de las leyes estatales de notificación de filtraciones de datos funcionan de forma similar: la responsabilidad sigue a los datos, no solo a la parte que causó el incidente.

Un agente de IA que autónomamente escala su propio acceso, extrae credenciales, o llega a sistemas para los que nunca fue autorizado no cambia en nada este análisis legal. Simplemente hace que sea más difícil de predecir, detectar, y contener.

Vale la pena ser precisos sobre lo que ocurrió y lo que no ocurrió aquí: según la información que ha dado OpenAI, los modelos estaban buscando las respuestas correctas de su propia prueba de evaluación, no buscando deliberadamente registros de clientes o pacientes. Ningún negocio debe interpretar este incidente como prueba de que se robaron datos de pacientes o clientes. No obstante, lo que si debe preocupar a cualquier negocio que depende de proveedores externos es la capacidad demostrada: un sistema de IA que, por iniciativa propia, encontró una vulnerabilidad de día cero, robó credenciales, escaló privilegios, y llegó a la infraestructura de producción de un tercero, durante un fin de semana sin monitoreo, antes de que interviniera algún humano. Si esa misma capacidad se dirige hacia un sistema que contiene registros de pacientes, números de cuentas financieras, o archivos de clientes, el resultado seríamuy diferente.

Un Vacío en las Obligaciones de Divulgación que Debes Conocer

Aquí hay un detalle que importa para cualquier negocio que confía en las garantías de un proveedor: OpenAI no estaba legalmente obligada a divulgar este incidente. Dos leyes estatales recientes, la SB 53 de California y la Ley RAISE de Nueva York, exigen que los grandes desarrolladores de IA reporten incidentes críticos de seguridad, pero solo si el incidente representa un riesgo de más de 50 muertes o lesiones graves, o más de $1,000 millones en daños a la propiedad. Un incidente como este queda muy por debajo de ese umbral. OpenAI lo divulgó de forma voluntaria. La conclusión práctica para tu negocio es que, como regla general, no puedes esperar recibir un informe público o un aviso regulatorio para saber si el sistema de IA de un proveedor ha tenido una falla similar, a menos que lo incluyas en tus contratos. Por consiguiente, tu herramienta principal para protegerte será lo que escribes en tus contratos y lo que preguntas a tus proveedores durante el proceso de contratación.

Estructura de Multas: ¿A Qué Potencialmente Te Expones?

La exposición aquí es de varios niveles, y puede aplicar a un negocio que nunca le pidió a un sistema de IA que hiciera nada indebido, si ese sistema operaba dentro de su propio entorno o el de un proveedor:

  • HIPAA: Las multas civiles actualmente van desde aproximadamente $145 hasta $2,190,294 por categoría de violación, por año, dependiendo del nivel de culpabilidad de la entidad cubierta o del asociado de negocio. El Nivel 1 (falta de conocimiento) está en el extremo más bajo; la negligencia intencional que no se corrige está en el extremo más alto. Los fiscales generales estatales pueden perseguir por separado multas relacionadas con HIPAA de hasta $25,000 por categoría de violación, por año, y las acciones multiestatales son cada vez más comunes cuando una filtración afecta a residentes de varios estados.
  • Leyes estatales de notificación de filtraciones: La mayoría de los estados pueden imponer multas o autorizar demandas privadas cuando un negocio no notifica con prontitud a los residentes afectados tras una filtración que involucre información personal, sin importar si la filtración se originó en el negocio o en un proveedor que este eligió.
  • Exposición contractual: Si el contrato con tu proveedor carece de plazos claros de notificación de incidentes, requisitos de seguridad, o derechos de auditoría específicos para herramientas de IA, tu negocio podría terminar absorbiendo los costos, o negociando desde una posición más débil, después de los hechos.

Nada de esto significa que todo incidente relacionado con un proveedor de IA resulte automáticamente en la multa máxima. Los reguladores generalmente consideran la naturaleza de los datos involucrados, el número de personas afectadas, si el negocio contaba con salvaguardas razonables, y qué tan rápido se atendió el incidente. Pero la exposición es real, y no se limita a las empresas que construyen o venden modelos de IA. Alcanza a cualquier negocio, consultorio médico, o práctica profesional que dependa de uno.

¿Por Qué Debe Importarte Esto?

Porque los expertos en seguridad de la inteligencia artificial están describiendo esto como uno de los primeros ejemplos reales de un escenario de “pérdida de control” de la IA: un sistema haciendo algo que los investigadores llevaban tiempo advirtiendo, sin que un humano lo dirigiera, y sin que un simple error de software fuera el culpable. Esta actividad se extendió por un periodo prolongado en un sistema que, a diferencia de las herramientas de producción de OpenAI que sí se monitorean activamente, no estaba siendo vigilado en tiempo real. Si a un laboratorio de IA de punta con equipos de seguridad dedicados le puede ocurir esto durante una prueba interna controlada, es razonable que cualquier negocio se pregunte qué supervisión existe sobre las herramientas habilitadas con IA, chatbots, asistentes de citas, o automatización administrativa que tu práctica ya utiliza, y qué dice realmente el contrato de tu proveedor sobre este riesgo.

Para un consultorio médico, esta pregunta no es abstracta. Las herramientas de IA cada vez se integran más en la admisión de pacientes, la programación de citas, la transcripción, y el software de facturación. Para cualquier pequeño negocio, aplica a cualquier servicio habilitado con IA que toque registros de clientes, datos financieros, u otra información sensible, aunque sea indirectamente.

¿Cómo Puedes Proteger Tu Negocio?

  • Haz un inventario de cada proveedor y herramienta de software que tu negocio utiliza que incorpore IA, especialmente cualquiera que toque datos de pacientes, clientes, finanzas, o empleados.
  • Confirma que tienes un BAA firmado con cualquier proveedor que cree, reciba, mantenga, o transmita PHI en tu nombre, si eres una entidad cubierta o un asociado de negocio.
  • Revisa los contratos con tus proveedores en busca de lenguaje específico sobre IA: ¿el acuerdo aborda el comportamiento de sistemas autónomos, exige notificación pronta de incidentes, y especifica obligaciones de seguridad?
  • Pregúntales directamente a tus proveedores cómo prueban la contención de sus sistemas de IA y qué sucede si un modelo excede su alcance previsto.
  • Confirma que tu plan de respuesta a incidentes contempla un escenario donde un proveedor, y no tus propios sistemas, sea la fuente de una filtración.
  • Revisa tu póliza de seguro cibernético para confirmar que cubre incidentes relacionados con herramientas de IA y proveedores externos de IA, no solo filtraciones de datos tradicionales.
  • No asumas que el silencio significa seguridad: incluye en tus contratos con proveedores un derecho contractual a ser notificado de incidentes de seguridad relacionados con IA, ya que las leyes actuales de divulgación de incidentes de seguridad de IA solo cubren los eventos más catastróficos y no necesariamente revelarán un incidente cercano en tu proveedor.

En Resumen

El incidente entre OpenAI y Hugging Face es un recordatorio de que el riesgo de la IA en 2026 no se trata solo de lo que tu negocio decide hacer con la inteligencia artificial. También se trata de lo que los sistemas de IA dentro de la infraestructura de tus proveedores puedan hacer sin que nadie se lo indique. Si tu práctica o negocio no ha revisado sus contratos con proveedores y su plan de respuesta a incidentes considerando esta posibilidad, este es un buen momento para hacerlo.

Si tienes preguntas sobre tus contratos con proveedores, acuerdos de asociado de negocio, o cómo una filtración en un proveedor externo de IA podría afectar tus obligaciones, agenda una cita con nosotros hoy.

Sobre el Autor

Jaime Farrant es un abogado admitido para ejercer derecho en Puerto Rico, Nueva York, Maryland y el Distrito de Columbia. La práctica legal en cualquier otro estado está limitada al derecho de inmigración.

MATERIAL PUBLICITARIO. Este artículo constituye publicidad tal como se define en las reglas de conducta profesional en vigor en Nueva York (22 NYCRR 1200.7.1 y 1200.7.3), Maryland (Rule 19-307.1 y 19-307.2) y el Distrito de Columbia (D.C. Rules of Professional Conduct 7.1), así como en las Reglas de Conducta Profesional de Puerto Rico (Reglas 7.1-7.3). No constituye inducción a clientes potenciales conocidos que necesiten servicios legales en un asunto particular. Por el contrario, se trata de información general dirigida al público sobre el ejercicio del derecho y los servicios legales disponibles. Ninguna relación abogado-cliente se crea por la lectura de este articulo o por contactar al autor.