SB1047 fue una mala idea. Pero el último SB53 del Senador Wiener está en el camino correcto, y es importante reconocer el progreso. Aquí está mi razonamiento. Mi enfoque para regular tecnologías novedosas como los modelos es: no sabemos cómo definir una mitigación y aseguramiento "buenos", pero lo sabremos cuando—y si—lo veamos. Hay dos implicaciones. #1. No deberíamos prescribir umbrales de riesgo o estándares de cuidado para el desarrollo de modelos. No podemos ponernos de acuerdo sobre los riesgos que importan, cómo medirlos o cuánto es demasiado. La única guía para desarrolladores, reguladores y tribunales es un conjunto de prácticas incipientes determinadas principalmente por empresas de código cerrado que dependen de muros de pago para hacer el trabajo pesado. Hacerlo podría enfriar la innovación abierta al exponer a los desarrolladores a una responsabilidad vaga o aumentada por la liberación generalizada. Eso fue SB1047 en pocas palabras, junto con ~5 equivalentes que inspiró en todo EE. UU. esta sesión, como el RAISE Act en NY. Deberíamos evitar ese enfoque. Estas propuestas son—en aspectos estrechos pero cruciales—demasiado ambiciosas. Y aún así: #2. Necesitamos arrojar luz sobre las prácticas de la industria para entender mejor la diligencia, o la falta de ella, aplicada por diferentes empresas. Si los desarrolladores tienen que comprometerse a una política de seguridad y protección, mostrar su trabajo y dejar un rastro documental, podemos evaluar mejor la solidez de sus afirmaciones, monitorear riesgos emergentes y decidir sobre futuras intervenciones. Ese es el Acta de IA de la UE y el Código de Práctica final en pocas palabras, que tanto OpenAI como Mistral han respaldado, y también es la última versión del SB53 de @Scott_Wiener. Si vamos a regular el desarrollo de modelos, ese es fundamentalmente el mejor enfoque: regular la transparencia—no las capacidades, mitigaciones o riesgos aceptables. Esto daría al menos a una jurisdicción de EE. UU. la autoridad de supervisión de Bruselas, y evitaría efectos no deseados en el desarrollo abierto. Para ser claros, todavía hay icebergs por delante: > Complejidad. Ya sea Big Tech o no, estas son obligaciones de documentación e informes onerosas. Hablando tácticamente, cuanto más complejo, más vulnerable se volverá este proyecto de ley. > Incentivos. La obligación de informar públicamente sobre evaluaciones de riesgo voluntarias crea un incentivo perverso para que los desarrolladores no prueben adecuadamente sus modelos y hagan la vista gorda ante riesgos difíciles. Permitir que los desarrolladores divulguen sus resultados a auditores o agencias en lugar de públicamente puede ayudar a promover una mayor sinceridad en sus evaluaciones internas. > Caballo de Troya. La cultura hiperactiva de California de modificar y enmendar puede dificultar la evaluación de estos proyectos de ley. Si SB53 se convierte en un proyecto de ley de estándar de cuidado como SB1047 o RAISE, debería ser rechazado por las mismas razones que antes. Cuantos más adornos se añadan a este árbol de Navidad, más contencioso será el proyecto de ley. > Amplitud. El proyecto de ley lanza una red amplia con definiciones expansivas de riesgo catastrófico y capacidad peligrosa. Para un proyecto de ley de "informes obligatorios / prácticas voluntarias", funcionan. Si este proyecto de ley fuera un proyecto de ley de estándar de cuidado, serían inviables. En resumen: un aplauso para el Senador Wiener por involucrarse y responder de manera reflexiva a los comentarios durante el año pasado. Es refrescante ver un proyecto de ley que realmente se basa en críticas anteriores. Todavía hay muchos caminos que este proyecto de ley podría tomar—y ha evolucionado mucho más allá de la propuesta original de denuncia—pero la trayectoria es prometedora.