SB1047 fue una mala idea. Pero la última SB53 del senador Wiener está en el camino correcto y es importante destacar el progreso. Aquí está mi razonamiento. Mi enfoque para regular la tecnología novedosa como los modelos es: no sabemos cómo definir la "buena" mitigación y la garantía, pero lo sabremos cuando lo veamos. Hay dos implicaciones. #1. No debemos prescribir umbrales de riesgo o estándares de atención 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 mayor por la publicación generalizada. Eso fue SB1047 en pocas palabras, junto con ~ 5 equivalentes que inspiró en los EE. UU. en esta sesión, como la Ley RAISE en Nueva York. Debemos evitar ese enfoque. Estas propuestas están, en aspectos estrechos pero cruciales, demasiado lejos de sus esquís. Y sin embargo: #2. Necesitamos arrojar luz sobre las prácticas de la industria para comprender mejor la diligencia, o la falta de ella, aplicada por diferentes empresas. Si los desarrolladores tienen que comprometerse con una política de seguridad y protección, mostrar su trabajo y dejar un rastro de papel, podemos evaluar mejor la solidez de sus afirmaciones, monitorear el riesgo emergente y decidir sobre la intervención futura. Esa es la Ley de IA de la UE y el Código de Prácticas final en pocas palabras, que tanto OpenAI como Mistral han respaldado, y también es la última versión de SB53 de @Scott_Wiener. Si vamos a regular el desarrollo de modelos, ese es fundamentalmente el mejor enfoque: regular la transparencia, no las capacidades, las mitigaciones o el riesgo aceptable. Le daría al menos una jurisdicción estadounidense a 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. Big Tech o no, estas son obligaciones onerosas de documentación e informes. Tácticamente hablando, cuanto más complejo, más vulnerable se volverá este proyecto de ley. > Incentivos. La notificación pública obligatoria de las evaluaciones voluntarias de riesgos crea un incentivo perverso para que los desarrolladores prueben sus modelos y hagan la vista gorda ante los riesgos difíciles. Permitir que los desarrolladores divulguen sus resultados a auditores o agencias en lugar de hacerlo públicamente puede ayudar a promover una mayor franqueza en sus evaluaciones internas. > caballo de Troya. La cultura hiperactiva de California puede dificultar la investigación de estos proyectos de ley. Si SB53 se transforma en un proyecto de ley estándar de atención como SB1047 o RAISE, debería ser rechazado por las mismas razones que antes. Cuantas más chucherías se agreguen a este árbol de Navidad, más polémico será el proyecto de ley. > Amplitud. El proyecto de ley arroja una amplia red 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 estándar de atención, serían inviables. En resumen: me quito el sombrero ante el senador Wiener por participar y responder cuidadosamente 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 de irregularidades, pero la trayectoria es prometedora.