Tôi đã xây dựng một AI Incident Copilot không lưu trữ logs của bạn

Mọi kỹ sư đều làm điều này.

Có lỗi xảy ra trên môi trường production. Bạn lấy logs. Bạn dán chúng vào một cửa sổ chat AI. Bạn yêu cầu trợ giúp. AI đưa ra một câu trả lời tốt.

Hầu hết mọi người nghĩ điều này là bình thường. Nhưng không phải vậy. Đó là một rủi ro bảo mật cực kỳ lớn.

Logs trên production chứa dữ liệu nhạy cảm. Chúng bao gồm ID khách hàng, lỗi xác thực (auth errors), stack traces và các phản hồi API. Đôi khi chúng thậm chí còn chứa cả các thông tin bí mật (secrets).

Cách debug hiện tại là dán dữ liệu riêng tư vào một hộp chat và hy vọng mọi chuyện sẽ ổn. Tôi muốn có sự trợ giúp của AI mà không phải đối mặt với rủi ro rò rỉ dữ liệu.

Vì vậy, tôi đã xây dựng một AI incident copilot. Tôi tuân theo một quy tắc duy nhất: Ứng dụng phải hữu ích ngay cả khi chúng tôi từ chối lưu trữ dữ liệu của bạn.

Ứng dụng đóng vai trò như một phòng tác chiến (war room) AI. Bạn dán logs, traces hoặc các lỗi vào. Nó giúp bạn:

• Tóm tắt các thay đổi • Tìm các điểm gây lỗi • Nhóm các logs gây nhiễu • Giải thích stack traces • Đề xuất các bước giảm thiểu • Phác thảo dòng thời gian phân tích sau sự cố (postmortem)

Hầu hết các nhà phát triển xây dựng ứng dụng theo cách này: Input → Backend → Database → LLM → Database → UI.

Đó là một cách xây dựng nguy hiểm. Giờ đây, ứng dụng của bạn sở hữu một kho lưu trữ về mọi sự cố trên production. Bạn phải lo lắng về các vụ vi phạm dữ liệu, sao lưu và quyền truy cập của quản trị viên.

Tôi muốn một sổ ghi chép riêng tư (private scratchpad), chứ không phải một bảng điều khiển SaaS.

Quy tắc thiết kế của tôi là: Xử lý dữ liệu, đừng thu thập nó.

Kiến trúc hoạt động theo cách khác:

  • Lịch sử chat nằm lại trong trình duyệt của bạn.
  • Backend không lưu các prompt.
  • Backend không lưu các phản hồi của mô hình.
  • Mỗi yêu cầu đều là tạm thời (disposable).

Tôi đã sử dụng Icelake AI API vì nó phù hợp với mô hình quyền riêng tư này. Máy chủ thực hiện ba bước:

  1. Che dấu (redact) các giá trị nhạy cảm.
  2. Gửi một prompt đã được tối giản đến API.
  3. Trả về câu trả lời mà không lưu trữ yêu cầu.

Việc che dấu dữ liệu (redaction) có giúp ích, nhưng nó không phải là một lá chắn ma thuật. Nó sẽ không bắt được mọi thứ. Thành công thực sự nằm ở việc giảm thiểu lượng dữ liệu bạn giữ lại sau khi yêu cầu kết thúc.

Redaction làm giảm rủi ro trong quá trình gọi API. Việc không lưu trữ logs làm giảm rủi ro mãi mãi.

Hầu hết các ứng dụng AI đều hỏi: Chúng ta có thể thu thập được gì? Ứng dụng này hỏi: Chúng ta có thể tránh thu thập được gì?

Cách tiếp cận này giúp sản phẩm tốt hơn. Người dùng cảm thấy an toàn. Họ sẵn sàng sử dụng nó trong các sự cố thực tế vì họ biết rằng những thông tin của họ không bị lưu trữ vào cơ sở dữ liệu của tôi.

Làn sóng ứng dụng AI tiếp theo không nên chỉ cạnh tranh về việc chúng thông minh đến mức nào. Chúng nên cạnh tranh về sự tiết chế (restraint).

Hãy tự hỏi bản thân: • Bạn từ chối lưu trữ điều gì? • Bạn làm điều gì khiến chính mình cũng không thể truy cập được? • Điều gì sẽ biến mất khi phiên làm việc kết thúc?

Các công cụ AI nên hữu ích vì chúng không ghi nhớ mọi thứ.

Source: https://dev.to/bart_holden_0d0cf2aaa0424/i-built-an-ai-incident-copilot-that-does-not-store-your-production-logs-3l0p

Optional learning community: https://t.me/GyaanSetuAi