Thảm họa không xảy ra vì có người đã ra tay ngăn nó

Những thập kỷ đầu của máy tính, bộ nhớ rất đắt, nên nhiều chương trình lưu năm bằng hai chữ số: 1975 thành "75". Khi năm 1999 chuyển sang 2000, các hệ thống đó có thể đọc "00" thành 1900. Điều này có thể làm hỏng việc tính lãi, xếp lịch, lập hóa đơn, điều khiển lưới điện và rất nhiều hệ thống khác phụ thuộc vào ngày tháng.

Suốt cuối những năm 1990, ngân hàng, hãng hàng không, công ty điện nước và chính phủ rà soát hàng triệu dòng code cũ, sửa hoặc thay những gì tìm thấy. Bộ Thương mại Mỹ ước tính riêng nước Mỹ sẽ chi khoảng 100 tỉ USD cho vấn đề này trong giai đoạn 1995 đến 2001. Ước tính cho toàn thế giới vào khoảng gấp đôi.

Khi đồng hồ chạm ngày 1/1/2000, có vài lỗi lẻ tẻ, như ngày tháng sai trên một số trang web và hóa đơn, nhưng điện, nước, ngân hàng và các chuyến bay đều không sụp đổ.

Quyết định then chốt là coi một rủi ro kỹ thuật khô khan như một hạn chót thật, và chi tiền trước khi có gì hỏng. Lãnh đạo đặt mốc thời gian rõ ràng, công khai báo cáo tiến độ và thử nghiệm hệ thống từ trước. Vì việc sửa thành công, nhiều người sau này lại cho rằng mọi chuyện đã bị thổi phồng. Hiện tượng này đôi khi được gọi là nghịch lý phòng ngừa: khi phòng ngừa hiệu quả, nó gần như chẳng để lại gì để thấy.

Góc nhìn AI: nhiều rủi ro với hệ thống AI cũng âm thầm, chậm rãi và mang tính kỹ thuật, như lỗi ẩn trong dữ liệu hay code chưa ai kiểm tra. Tìm và sửa sớm rẻ hơn nhiều so với dọn dẹp sau sự cố, kể cả khi chẳng ai cảm ơn bạn vì điều đó.

Ý tưởng đằng sau vụ nàyBài học: Duyệt bài AI như một người quản lý →

1. 1Liệt kê các hệ thống bạn phụ thuộc vào, và tìm hiểu cái gì sẽ hỏng nếu một trong số đó trục trặc.
2. 2Đặt hạn chót rõ ràng để sửa các rủi ro đã biết, và thử bản sửa trước khi hạn chót đến.
3. 3Đánh giá một nỗ lực phòng ngừa theo những gì nó đã ngăn được, đừng theo việc có ai thấy thảm họa hay không.
4. 4Ghi chép đơn giản cách hệ thống của bạn hoạt động, để người sau còn sửa được.