AWS Lambda launches enhanced observability for Kafka event source mappings (ESM) that provides Amazon CloudWatch Logs and metrics to monitor event polling setup, scaling, and processing state of Kafka events. This capability allows customers to quickly diagnose setup issues and take timely corrective actions to operate resilient data streaming workloads. This capability is available for both Amazon Managed Streaming for Apache Kafka (Amazon MSK) and self-managed Apache Kafka (SMK) event source mappings.
Customers use Kafka event source mappings (ESM) with their Lambda functions to build mission-critical applications. However, the lack of visibility into event polling setup, scaling, and processing state for events slows down troubleshooting for issues resulting from faulty permissions, misconfiguration, or function errors, which increases mean time to resolution and adds operational overhead. With this launch, customers can enable CloudWatch Logs and metrics to monitor their Kafka polling setup, scaling, and event processing state. Customers can select from multiple log level options that provide logs ranging from warnings and errors to detailed information about event processing progress. Similarly, customers can enable one or more metrics groups—EventCount, ErrorCount, and KafkaMetrics—to monitor various aspects of event processing. Customers can view all their metrics and logs via a dedicated monitoring page on AWS Console for ESM. This capability allows customers to utilize their observability tooling to quickly diagnose setup issues and track performance metrics to meet their stringent business requirements.
This feature is available in all AWS Commercial Regions where AWS Lambda’s Provisioned mode for Kafka ESM is available.
You can enable ESM logs and metrics for your Kafka ESM using AWS Lambda’s Create and Update ESM APIs, AWS Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS SAM. To learn more about these capabilities, visit the Lambda Kafka ESM developer documentation. These logs and metrics are charged at standard CloudWatch pricing.
AWS Lambda launches enhanced observability for Kafka event source mappings (ESM) that provides Amazon CloudWatch Logs and metrics to monitor event polling setup, scaling, and processing state of Kafka events. This capability allows customers to quickly diagnose setup issues and take timely corrective actions to operate resilient data streaming workloads. This capability is available for both Amazon Managed Streaming for Apache Kafka (Amazon MSK) and self-managed Apache Kafka (SMK) event source mappings. Customers use Kafka event source mappings (ESM) with their Lambda functions to build mission-critical applications. However, the lack of visibility into event polling setup, scaling, and processing state for events slows down troubleshooting for issues resulting from faulty permissions, misconfiguration, or function errors, which increases mean time to resolution and adds operational overhead. With this launch, customers can enable CloudWatch Logs and metrics to monitor their Kafka polling setup, scaling, and event processing state. Customers can select from multiple log level options that provide logs ranging from warnings and errors to detailed information about event processing progress. Similarly, customers can enable one or more metrics groups—EventCount, ErrorCount, and KafkaMetrics—to monitor various aspects of event processing. Customers can view all their metrics and logs via a dedicated monitoring page on AWS Console for ESM. This capability allows customers to utilize their observability tooling to quickly diagnose setup issues and track performance metrics to meet their stringent business requirements. This feature is available in all AWS Commercial Regions where AWS Lambda’s Provisioned mode for Kafka ESM is available. You can enable ESM logs and metrics for your Kafka ESM using AWS Lambda’s Create and Update ESM APIs, AWS Console, AWS CLI, AWS SDK, AWS CloudFormation, and AWS SAM. To learn more about these capabilities, visit the Lambda Kafka ESM developer documentation. These logs and metrics are charged at standard CloudWatch pricing.
Amazon RDS now supports Internet Protocol version 6 (IPv6) for VPC endpoints of RDS Service APIs, in addition to the existing IPv6 support for public endpoints. This allows you to configure dual-stack (IPv4 and IPv6) connectivity to access RDS Service APIs directly from within your VPC without internet traversal.
IPv6 provides an expanded address space, enabling you to scale your application on AWS beyond the limitations of IPv4 addresses. With IPv6, you can assign easy to manage contiguous IP ranges to micro-services and can get virtually unlimited scale for your applications. Moreover, with support for both IPv4 and IPv6, you can gradually transition applications from IPv4 to IPv6, enabling safer migration.
This feature is available in all commercial AWS regions and AWS GovCloud (US) regions. Get started with the RDS Service APIs here.
To learn more about configuring your environment for IPv6, please refer to the IPv6 User Guide.
Amazon RDS now supports Internet Protocol version 6 (IPv6) for VPC endpoints of RDS Service APIs, in addition to the existing IPv6 support for public endpoints. This allows you to configure dual-stack (IPv4 and IPv6) connectivity to access RDS Service APIs directly from within your VPC without internet traversal. IPv6 provides an expanded address space, enabling you to scale your application on AWS beyond the limitations of IPv4 addresses. With IPv6, you can assign easy to manage contiguous IP ranges to micro-services and can get virtually unlimited scale for your applications. Moreover, with support for both IPv4 and IPv6, you can gradually transition applications from IPv4 to IPv6, enabling safer migration. This feature is available in all commercial AWS regions and AWS GovCloud (US) regions. Get started with the RDS Service APIs here. To learn more about configuring your environment for IPv6, please refer to the IPv6 User Guide.
Today, Amazon SageMaker announced a new capability allowing you to establish connectivity between your Amazon Virtual Private Cloud (VPC) and Amazon SageMaker Unified Studio without customer data traffic going through the public internet. Customers needing to go beyond the standard data transfer protocol (HTTPS/TLS2) can choose to configure their VPC so data transfer stays within the AWS network.
Through AWS PrivateLink, Network Administrators can now onboard AWS service endpoints to their VPC used by Amazon SageMaker Unified Studio. With the endpoints are onboarded, IAM policies used by Amazon SageMaker will enforce that customer data stay within the AWS network.
Amazon SageMaker private access using AWS PrivateLink is available in all AWS Regions where Amazon SageMaker Unified Studio is supported, including: Asia Pacific (Tokyo), Europe (Ireland), US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), South America (São Paulo), Asia Pacific (Seoul), Europe (London), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), Asia Pacific (Mumbai), Europe (Paris), Europe (Stockholm)
Today, Amazon SageMaker announced a new capability allowing you to establish connectivity between your Amazon Virtual Private Cloud (VPC) and Amazon SageMaker Unified Studio without customer data traffic going through the public internet. Customers needing to go beyond the standard data transfer protocol (HTTPS/TLS2) can choose to configure their VPC so data transfer stays within the AWS network. Through AWS PrivateLink, Network Administrators can now onboard AWS service endpoints to their VPC used by Amazon SageMaker Unified Studio. With the endpoints are onboarded, IAM policies used by Amazon SageMaker will enforce that customer data stay within the AWS network. Amazon SageMaker private access using AWS PrivateLink is available in all AWS Regions where Amazon SageMaker Unified Studio is supported, including: Asia Pacific (Tokyo), Europe (Ireland), US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), South America (São Paulo), Asia Pacific (Seoul), Europe (London), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), Asia Pacific (Mumbai), Europe (Paris), Europe (Stockholm) To learn more, visit Amazon SageMaker then get started with the network isolation documentation.
Amazon Elastic Container Service (Amazon ECS) now publishes container health status as a new metric in CloudWatch Container Insights with enhanced observability. Customers can now track the operational health of their containers through a dedicated CloudWatch metric and create alarms to respond proactively to unhealthy containers.
When customers configure a container health check in the container definition of an ECS task definition, Container Insights now publishes the UnHealthyContainerHealthStatus metric in the ECS/ContainerInsights namespace. The metric reports 0 for HEALTHY and 1 for UNHEALTHY. Container health state information is also available in embedded metric format (EMF) logs, providing additional context while health checks are being evaluated during the UNKNOWN state. The metric is available across cluster, service, task, and container-level dimensions, enabling customers to monitor health at their preferred level of granularity. Customers can create CloudWatch alarms on the metric to receive notifications when containers become unhealthy, allowing teams to take immediate action and maintain application reliability.
To get started, enable Container Insights with enhanced observability on your ECS cluster and configure a container health check in your task definition to start collecting the metric in CloudWatch. Container health metric is available in all AWS Regions where Amazon ECS Container Insights is supported. For more information, see the Amazon ECS container health checks documentation and the CloudWatch Container Insights documentation.
Amazon Elastic Container Service (Amazon ECS) now publishes container health status as a new metric in CloudWatch Container Insights with enhanced observability. Customers can now track the operational health of their containers through a dedicated CloudWatch metric and create alarms to respond proactively to unhealthy containers. When customers configure a container health check in the container definition of an ECS task definition, Container Insights now publishes the UnHealthyContainerHealthStatus metric in the ECS/ContainerInsights namespace. The metric reports 0 for HEALTHY and 1 for UNHEALTHY. Container health state information is also available in embedded metric format (EMF) logs, providing additional context while health checks are being evaluated during the UNKNOWN state. The metric is available across cluster, service, task, and container-level dimensions, enabling customers to monitor health at their preferred level of granularity. Customers can create CloudWatch alarms on the metric to receive notifications when containers become unhealthy, allowing teams to take immediate action and maintain application reliability. To get started, enable Container Insights with enhanced observability on your ECS cluster and configure a container health check in your task definition to start collecting the metric in CloudWatch. Container health metric is available in all AWS Regions where Amazon ECS Container Insights is supported. For more information, see the Amazon ECS container health checks documentation and the CloudWatch Container Insights documentation.
Amazon RDS for Oracle now supports cross-Region replicas with additional storage volumes. With additional storage volumes, customers can add up to three storage volumes, each with up to 64 TiB, in addition to the primary storage volume for their database instance. As a result, customers get flexibility to add or remove storage with evolving workload demands, without incurring application downtime, and set up their database instance with up to 256 TiB storage. Now, with support for cross-Region replicas, customers that set up database instances with cross-Region replicas for business-critical applications also get the benefit of using additional storage volumes for storage flexibility.
When you create a cross-Region replica for a database instance that is set up with additional storage volumes, Amazon RDS for Oracle automatically configures the same storage layout on the replica. Subsequently, you can apply changes to additional storage volumes on the primary instance and the replica using the AWS Management Console, AWS CLI, or AWS SDK. In disaster recovery situations, you can promote a cross-Region replica to serve as the new standalone database, or execute a switchover to reverse roles between the primary database and the replica to meet low recovery point objective (RPO) and recovery time objective (RTO) for business critical applications.
You will need an Oracle Database Enterprise Edition (EE) license to use replicas in mounted mode, and an additional Oracle Active Data Guard license to use replicas in read-only mode. We recommend consulting your legal team or licensing expert to verify Oracle license requirements for your specific use case. Amazon RDS for Oracle cross-Region replicas with additional storage volumes is available in all AWS Regions including the AWS GovCloud (US) Regions. To learn more, see Amazon RDS for Oracle User Guide.
Amazon RDS for Oracle now supports cross-Region replicas with additional storage volumes. With additional storage volumes, customers can add up to three storage volumes, each with up to 64 TiB, in addition to the primary storage volume for their database instance. As a result, customers get flexibility to add or remove storage with evolving workload demands, without incurring application downtime, and set up their database instance with up to 256 TiB storage. Now, with support for cross-Region replicas, customers that set up database instances with cross-Region replicas for business-critical applications also get the benefit of using additional storage volumes for storage flexibility. When you create a cross-Region replica for a database instance that is set up with additional storage volumes, Amazon RDS for Oracle automatically configures the same storage layout on the replica. Subsequently, you can apply changes to additional storage volumes on the primary instance and the replica using the AWS Management Console, AWS CLI, or AWS SDK. In disaster recovery situations, you can promote a cross-Region replica to serve as the new standalone database, or execute a switchover to reverse roles between the primary database and the replica to meet low recovery point objective (RPO) and recovery time objective (RTO) for business critical applications. You will need an Oracle Database Enterprise Edition (EE) license to use replicas in mounted mode, and an additional Oracle Active Data Guard license to use replicas in read-only mode. We recommend consulting your legal team or licensing expert to verify Oracle license requirements for your specific use case. Amazon RDS for Oracle cross-Region replicas with additional storage volumes is available in all AWS Regions including the AWS GovCloud (US) Regions. To learn more, see Amazon RDS for Oracle User Guide.
Starting today, Amazon EC2 R8a instances are now available in Europe (Spain) and Europe (Frankfurt) Regions. These instances, feature 5th Gen AMD EPYC processors (formerly code named Turin) with a maximum frequency of 4.5 GHz, deliver up to 30% higher performance, and up to 19% better price-performance compared to R7a instances.
R8a instances deliver 45% more memory bandwidth compared to R7a instances, making these instances ideal for latency sensitive workloads. Compared to Amazon EC2 R7a instances, R8a instances provide up to 60% faster performance for GroovyJVM, allowing higher request throughput and better response times for business-critical applications.
Built on the AWS Nitro System using sixth generation Nitro Cards, R8a instances are ideal for high performance, memory-intensive workloads, such as SQL and NoSQL databases, distributed web scale in-memory caches, in-memory databases, real-time big data analytics, and Electronic Design Automation (EDA) applications. R8a instances offer 12 sizes including 2 bare metal sizes. Amazon EC2 R8a instances are SAP-certified, and providing 38% more SAPS compared to R7a instances.
Starting today, Amazon EC2 R8a instances are now available in Europe (Spain) and Europe (Frankfurt) Regions. These instances, feature 5th Gen AMD EPYC processors (formerly code named Turin) with a maximum frequency of 4.5 GHz, deliver up to 30% higher performance, and up to 19% better price-performance compared to R7a instances. R8a instances deliver 45% more memory bandwidth compared to R7a instances, making these instances ideal for latency sensitive workloads. Compared to Amazon EC2 R7a instances, R8a instances provide up to 60% faster performance for GroovyJVM, allowing higher request throughput and better response times for business-critical applications. Built on the AWS Nitro System using sixth generation Nitro Cards, R8a instances are ideal for high performance, memory-intensive workloads, such as SQL and NoSQL databases, distributed web scale in-memory caches, in-memory databases, real-time big data analytics, and Electronic Design Automation (EDA) applications. R8a instances offer 12 sizes including 2 bare metal sizes. Amazon EC2 R8a instances are SAP-certified, and providing 38% more SAPS compared to R7a instances. To get started, sign in to the AWS Management Console. For more information about the new instances, visit the Amazon EC2 R8a instance page.
Starting today, Amazon GameLift Streams provides streaming capabilities in six new locations – eu-west-2 (London), eu-north-1 (Stockholm), sa-east-1 (São Paulo), ap-south-1 (Mumbai), ap-northeast-2 (Seoul), and ap-southeast-2 (Sydney) for all customers.
New streaming locations enable customers to provide low latency streaming experiences to their players in Europe, South America, India, and Asia regions. Additionally, these locations increase overall GPU availability, enabling customers to scale their streaming services more effectively.
The service supports all stream classes in these new regions.
To get started, customers need to edit Location and capacity configurations to add new locations to their new or existing stream groups via console or CLI.
Starting today, Amazon GameLift Streams provides streaming capabilities in six new locations – eu-west-2 (London), eu-north-1 (Stockholm), sa-east-1 (São Paulo), ap-south-1 (Mumbai), ap-northeast-2 (Seoul), and ap-southeast-2 (Sydney) for all customers. New streaming locations enable customers to provide low latency streaming experiences to their players in Europe, South America, India, and Asia regions. Additionally, these locations increase overall GPU availability, enabling customers to scale their streaming services more effectively. The service supports all stream classes in these new regions. To get started, customers need to edit Location and capacity configurations to add new locations to their new or existing stream groups via console or CLI. For more details, see Amazon GameLift Streams developer guide: AWS Regions and remote locations
Today, AWS announces the launch of Partner Revenue Measurement, a new capability that gives AWS Partners visibility into how their solutions impact AWS service consumption across partner-managed and customer-managed accounts.
Partner Revenue Measurement allows Partners to better understand their AWS revenue impact and product consumption patterns. Partners can now tag AWS resources using the product code from their AWS Marketplace listing with tag key: aws-apn-id and tag value: pc:<AWS Marketplace product-code> to quantify and measure the AWS revenue impact of that solution.
Partner Revenue Measurement is generally available in all commercial regions. To learn more about implementing Partner Revenue Measurement, review the onboarding guide for more information.
Today, AWS announces the launch of Partner Revenue Measurement, a new capability that gives AWS Partners visibility into how their solutions impact AWS service consumption across partner-managed and customer-managed accounts.
Partner Revenue Measurement allows Partners to better understand their AWS revenue impact and product consumption patterns. Partners can now tag AWS resources using the product code from their AWS Marketplace listing with tag key: aws-apn-id and tag value: pc:<AWS Marketplace product-code> to quantify and measure the AWS revenue impact of that solution.
Partner Revenue Measurement is generally available in all commercial regions. To learn more about implementing Partner Revenue Measurement, review the onboarding guide for more information.
Lo que Jaron Lanier aprendió sobre la IA tras un encuentro con la ceguera – y una obsesión turbo alimentada con la joyería
Jaron Lanier, el visionario detrás de la realidad virtual, ha pasado décadas en la exploración de las promesas y trampas del mundo digital que ayudó a crear. Científico informático, músico y artista, Lanier cofundó la primera empresa de realidad virtual y popularizó esta tecnología revolucionaria. Nombrado una de las 100 personas más influyentes por la revista Time, también es autor de los best sellers You Are Not a Gadget y Who Owns the Future? En este artículo exclusivo para Signal, Lanier ofrece sus consejos para desbloquear el poder de la inteligencia artificial.
A principios de 2025 recibí un diagnóstico falso de que tal vez me quedaría ciego para primavera. Luego tuve que soportar un mes precipitado hasta que al final llegó la segunda opinión correctiva. Resulta que, durante ese mes, desarrollé una nueva obsesión creativa que se ha vuelto muy valiosa para mí. Y esa obsesión fue habilitada por la IA. Una de las razones por las que les cuento todo esto es que espero compartir algunas ideas sobre cómo sacar el máximo partido a la IA, pero esta confesión también podría ayudar a deshacer un malentendido común de que soy escéptico u opositor a la IA. En cambio, soy un entusiasta de la IA que piensa que muchos de nosotros pensamos en la IA de manera equivocada.
Cuando me dijeron que solo me quedaban unos meses de vista, hice todo lo posible por ver bien. Miraba plantas y animales. Tomaba paseos para admirar barrancos y atardeceres. Me detenía en ojos y rostros. Pero también me vi obligado a ir a una reunión donde no hay mucho que ver más que ecuaciones en una diapositiva.
Crecí en Nuevo México y adoraba la platería autóctona de niño, así que tras mi diagnóstico empecé a comprar anillos turquesa para contemplarlos en mis dedos durante largas conversaciones sobre operaciones de matriz. Muchos anillos, un número absurdo.
Qué alegría fue enterarme al final de ese largo mes que el primer especialista en retina se había equivocado. La razón me resultó un poco embarazosa. A principios de los años 80 colaboré en lo que tal vez fue la primera simulación quirúrgica, en Stanford Med, con Joe Rosen, cirujano, y Ann Lasko, ingeniera de nuestra startup VPL Research, que también fue la primera empresa de VR. Luego, hacia finales de siglo, me sometí a una cirugía láser retiniana por un problema menor. Resultó que el cirujano de retina conocía mis trabajos anteriores y me ofreció operar de manera breve el láser para colocar algunos puntos en mi retina. (Es obvio que no revelaré el nombre de este doctor.)
No pude evitarlo, tuve que añadir un poco de variación, un poco de arte, un movimiento a lo largo de un círculo de puntos láser. Así que tengo un pequeño tatuaje en la retina, algo que todavía no es tendencia entre los jóvenes, pero tiempo al tiempo. Fue esta desviación de la norma —que olvidé mencionar al primer especialista en retina— lo que lo alarmó.
Cuando recibí la buena noticia, mi aprecio no solo por la visión, sino también por la joyería, estaba supercargado. En cierto modo, el diagnóstico erróneo había sido una bendición. Me sentía ridículo por comprar cantidades excesivas de joyería, así que pasé a ser joyero. Al principio esto significaba trabajos sencillos de ensartado, pero luego pasé a trabajar con arcillas metálicas, después aprender a soldar de manera correcta, cortar y mucho martilleo y lijado – y después fundición, una cortadora láser y una fresadora CNC. Establecí contactos en Jaipur y Sumatra para conseguir gemas raras. Estaba sumergido en eso
Ensartar cuentas, la “droga de entrada” de la fabricación de joyas, es lo más fácil del mundo: solo consiste en combinar elementos bonitos y preexistentes con un agujero, sobre un alambre. Pero a nivel filosófico es bastante provocador. ¡Se parece a la IA! Piensen en esto: ¿Es creativo un collar de cuentas? Todo lo que haces es combinar cosas que han hecho otras personas. Y, sin embargo, una hilera de cuentas puede ser expresiva. Puede ser más que sus fuentes. Pero el valor es esquivo, para el ojo de quien lo mira. Necesitas una historia, un contexto, para apreciarla de verdad. Las cuentas existen desde hace decenas de miles de años, y cada pieza de joyería fue una historia en su tiempo, y una historia en evolución para nosotros ahora.
No se puede ver por completo mi trabajo con las cuentas sin saber que yo pensaba que iba a quedarme ciego. La historia tiene que formar parte de las cuentas para que en verdad brillen. Las cuentas, en abstracto, no son cuentas.
Mi reputación de escéptico de la IA viene porque discuto mucha filosofía con mis colegas del campo. La forma usual de hablar de la IA es decir que creamos una especie de nueva entidad, y que todo lo que está mal con ella —como las alucinaciones— es un defecto que hay que corregir en esa entidad. Se supone que esa entidad será al final una fuente general de valor, y no solo algo con usos específicos. Son ideas tan comunes que ni siquiera notamos que son elecciones, pero yo no las comparto.
Prefiero pensar en la IA como la forma más productiva de colaboración humana que hemos tenido. No hay “nadie en casa” dentro de una IA; no hay una entidad. Solo están todas las personas cuyos datos fueron usados para entrenarla. Me gusta este enfoque porque hace más fácil imaginar futuros positivos para la civilización que la idea de que la gente se volverá obsoleta a nivel económico. Pero esa es la visión amplia; quiero centrarme aquí en lo personal e íntimo.
Hacer joyería es difícil. Cuando era niño en Nuevo México, pregunté a algunos artesanos navajos si podían enseñarme algo, y estuvieron encantados, pero me advirtieron que tomaría años aprender. Eso era antes. El mundo digital no eclipsó la joyería física, sino que la acercó más.
El video en línea es el nuevo maestro universal de habilidades físicas, y me ayudó mucho. (Quienes siguen mi trabajo saben que también me preocupa el daño psicológico y social que pueden causar las plataformas digitales, pero sus usos positivos también son reales.) Sin embargo, los videos no son buenos para aprender detalles bajo demanda. Puedes ver un tutorial sobre cómo alguien hizo un anillo, lo cual puede ser revelador, pero si intentas resolver un problema específico, quizá tengas que ver decenas de videos y aun así no encuentres la respuesta. ¿Qué arcillas de modelado no se contraen si las usas para mantener un espacio dentro de un engaste en una arcilla metálica sinterizada? La respuesta existe, pero es difícil de localizar. Así que preguntas en foros. Pero estos pueden tardar en responder, y desviarse del tema con frecuencia.
La IA es una amalgama de los datos de las personas. Al hacer un gran modelo, traemos muchos datos bajo análisis estadístico, se detectan patrones en palabras, sonidos, pixeles… en verdad cualquier cosa que se pueda digitalizar. Luego esos patrones se usan para crear respuestas. Eso es la IA en esencia: detectar patrones y extrapolar.
La forma usual de pensar la IA sugiere que el usuario debe tratar el programa como un socio, como otra entidad. No me parece la mentalidad más útil. Si formulo una pregunta, el modelo intenta responder como otras personas han respondido antes. Eso aumenta la probabilidad de que la respuesta vaya más allá de lo que los datos justifican —porque así hablaba la gente cuya información se usó para entrenar el modelo—. Eso es lo que ocurre cuando la IA parece adelantarse a los hechos: lo que llamamos “alucinación”.
Si en cambio pregunto, por ejemplo: “¿Otros joyeros han tenido éxito al fresar jade y la plata en la que está engastado en un solo trabajo CNC sin cambios de herramienta?”, entonces el modelo me cuenta historias sobre lo que ha funcionado a otras personas. Es más concreto. Si le pregunto al modelo de manera directa como si supiera cosas, es casi como si le rogara que invente. No hay una sola respuesta general: cada pieza de joyería es única, como lo es cada taller. La respuesta a un planteamiento general se vuelve menos confiable y además ignora la maravillosa variedad del oficio. Al preguntar qué ha funcionado para otros, anclo el uso de la IA a su verdadera naturaleza y obtengo un conjunto de respuestas reales, no una respuesta sintética que no existe en el mundo real.
Usar IA con esta mentalidad aporta beneficios personales además de productividad. Cuando uso la IA para dirigir mi investigación en lugar de perderme en chats o videos, tengo más control. Cuando le pregunto dónde está una opción escondida en un enorme programa de diseño 3D, puedo trabajar de inmediato; antes tenía que revisar documentación durante horas o días. Cuanto más dirigido soy, más valor obtengo y menos siento que la IA me reemplaza.
Quienes tratan al modelo como un compañero deben cargar con el costo emocional y operativo de simular una relación. Me parece que sustituyen un nuevo tipo de demora, justo la que la IA debería eliminar. Además, simular una relación consume cómputo —es decir, energía— en el backend. Así que hay un impuesto tanto para el usuario como para la máquina cuando se simula a un compañero en lugar de usar una herramienta. Pero entiendo que cada persona es distinta. Sin juicios: solo cuento lo que a mí me funciona.
Otro principio que sigo es recordar que la tecnología siempre es específica. Algunos quieren pensar que la IA algún día será general por completo, y capaz de resolver cualquier problema. Me niego a entrar en discusiones sobre si soy escéptico respecto a cuán buena será la IA. Ese no es el punto. El punto es que, si piensas de manera concreta en lo que es la IA hoy —cómo funciona hoy—, puedes usarla mejor. Eso hace que la IA sea algo específico, aunque muy poderoso. Y aunque en el futuro sea otra cosa, la única que puedes usar es la que existe ahora.
Una cosa que la IA puede hacer es extrapolar patrones. Incluso si no existe un tratado sobre una técnica joyera esotérica, no pasa nada si el modelo extrapola a través de patrones de lenguaje. Si lo incitas a resolver un problema como si estuvieras seguro de que la solución ideal ya existe, podría inventar cosas para responder. Por otro lado, si pides una especulación informada basada en técnicas que otras personas han usado —quiénes son, qué intentaron, qué funcionó y qué no—, entonces estos tipos de preguntas ancladas evitan las alucinaciones, incluso cuando se avanza un poco más allá de lo que ya se sabe.
No creo que exista tal cosa como una alucinación de IA, en realidad. Solo expectativas mal alineadas del usuario. Un modelo usado de manera concreta puede equivocarse, pero no puede alucinar, porque no se le dio un escenario para hacerlo. Prueben este enfoque y vean si les funciona.
Por último, noten que no tiene sentido preocuparse por si en verdad hicieron algo, o si la IA lo hizo por ustedes. Todo lo que hagan solo es significativo en el contexto que ustedes crearon. Combinar cuentas no es difícil, y sería más o menos fácil que un algoritmo lo hiciera bien como para pasar una “prueba de Turing de cuentas”, pero esa es una forma engañosa de verlo. Las cuentas cuentan una historia, y el valor está en la historia junto a las cuentas. El punto de mis piezas era que eran una respuesta a mi miedo de quedarme ciego. La IA no vivió esa historia; yo sí. El valor perdurable siempre está arraigado en la realidad.
Usar IA me ayudó a aprender joyería a una velocidad casi absurda. Sentí libertad y autonomía. He hecho al menos una pieza al día desde que comencé, y muchas de ellas son bastante buenas. Me gusta usarlas. Me gusta ver a otras personas usar piezas que hice. No se trata de la IA, y eso es justo lo que hace que la IA sea buena.
You can now change the server-side encryption type of encrypted objects in Amazon S3 without any data movement. You can use the UpdateObjectEncryption API to atomically change the encryption key of your objects regardless of the object size or storage class. With S3 Batch Operations, you can use UpdateObjectEncryption at scale to standardize the encryption type on entire buckets of objects while preserving object properties and S3 Lifecycle eligibility.
Customers across many industries face increasingly stringent audit and compliance requirements on data security and privacy. A common requirement for these compliance frameworks is more rigorous encryption standards for data-at-rest, where organizations must encrypt data using a key management service. With UpdateObjectEncryption, customers can now change the encryption type of existing encrypted objects to move from Amazon S3 managed server-side encryption (SSE-S3) to use server-side encryption with AWS KMS keys (SSE-KMS). You can also change the customer-managed KMS key used to encrypt your data to comply with custom key rotation standards or enable the use of S3 Bucket Keys to reduce your KMS requests.
The Amazon S3 UpdateObjectEncryption API is available in all AWS Regions. To get started, you can use the AWS Management Console or the latest AWS SDKs to update the server-side encryption type of your objects. To learn more, please visit the documentation.
You can now change the server-side encryption type of encrypted objects in Amazon S3 without any data movement. You can use the UpdateObjectEncryption API to atomically change the encryption key of your objects regardless of the object size or storage class. With S3 Batch Operations, you can use UpdateObjectEncryption at scale to standardize the encryption type on entire buckets of objects while preserving object properties and S3 Lifecycle eligibility. Customers across many industries face increasingly stringent audit and compliance requirements on data security and privacy. A common requirement for these compliance frameworks is more rigorous encryption standards for data-at-rest, where organizations must encrypt data using a key management service. With UpdateObjectEncryption, customers can now change the encryption type of existing encrypted objects to move from Amazon S3 managed server-side encryption (SSE-S3) to use server-side encryption with AWS KMS keys (SSE-KMS). You can also change the customer-managed KMS key used to encrypt your data to comply with custom key rotation standards or enable the use of S3 Bucket Keys to reduce your KMS requests. The Amazon S3 UpdateObjectEncryption API is available in all AWS Regions. To get started, you can use the AWS Management Console or the latest AWS SDKs to update the server-side encryption type of your objects. To learn more, please visit the documentation.
