AI là trợ lý của hội đồng điều tra: từ tác tử đám mây đến điều tra sự cố ngoại tuyến

Cách chúng tôi đi từ những thử nghiệm đầu tiên trên đám mây đến quy trình vận hành “công cụ che giấu dữ liệu → tác tử AI → khôi phục dữ liệu gốc”, sau đó xây dựng hệ thống điều tra ngoại tuyến thử nghiệm và đang chuẩn bị cho bước tiếp theo — môi trường AI doanh nghiệp bảo mật Fire.

Ý tưởng chính: AI không được “chỉ định người có lỗi” và không thay thế hội đồng. Vai trò hữu ích của nó là giúp hội đồng nhanh chóng ghép các tài liệu rời rạc thành một bức tranh thống nhất, nhìn ra những khoảng trống, kiểm tra logic nhân quả và chuẩn bị bản dự thảo làm việc đầu tiên của cuộc điều tra.

Mọi chuyện bắt đầu từ đâu

Chúng tôi bắt đầu thử dùng AI trong điều tra sự cố từ năm 2023. Khi đó, ý tưởng trông khá đơn giản: tạo một tác tử riêng, nạp vào đó phương pháp luận điều tra và tài liệu của một sự việc cụ thể, rồi yêu cầu nó dựng dòng thời gian, tìm mâu thuẫn trong các bản tường trình, đề xuất nguyên nhân và biện pháp.

Năm 2024, khả năng của các mô hình mở rộng rõ rệt: chúng bắt đầu xử lý tốt không chỉ văn bản mà cả hình ảnh. Một trong những thử nghiệm đầu tiên thậm chí không phải là một cuộc điều tra đầy đủ. Tại một cơ sở ở vùng xa, một nữ công nhân bị ngã và chấn thương chân. Ảnh chụp X-quang được thực hiện ngay tại chỗ, nhưng ở đó không có chuyên gia có thể đọc kết quả ngay. Chúng tôi tải ảnh chụp lên AI, và mô hình chỉ ra một vùng trông giống vết gãy xương bàn chân thứ năm.

Tôi cố ý nhấn mạnh: đó không phải là kết luận y khoa và cũng không được phép là như vậy. Việc đánh giá cuối cùng một hình ảnh y khoa là nhiệm vụ của bác sĩ. Nhưng với chúng tôi, sự việc đó là một tín hiệu kỹ thuật quan trọng: mô hình có khả năng nhận ra những chi tiết trên hình ảnh mà người không chuyên có thể bỏ sót. Nghĩa là trong điều tra, nó có tiềm năng làm việc không chỉ với văn bản mà còn với sơ đồ, ảnh chụp và các tài liệu khác.

Phương án làm việc đầu tiên: tác tử đám mây

Khi các tác tử tùy chỉnh ổn định hơn xuất hiện, chúng tôi bắt đầu thiết lập chúng trực tiếp theo phương pháp luận của doanh nghiệp. Chúng tôi làm các phiên bản trên GPT, Gemini và Perplexity; ở giai đoạn đầu cũng thử cả Grok. Tác tử được nạp phương pháp luận, sau đó là các bản tường trình, mô tả ban đầu, từng văn bản riêng lẻ và các tài liệu khác.

Hiệu quả thực tế thấy được ngay. AI nhanh chóng đối chiếu các lời khai, đề xuất trình tự sự việc, phát hiện chỗ không khớp về thời gian và cách diễn đạt, lập danh sách câu hỏi bổ sung. Với hội đồng, nó hữu ích như một “nhà phân tích thứ hai” không biết mệt khi đọc đi đọc lại hàng chục trang tài liệu.

Nhưng phương án đầu tiên có một khiếm khuyết rõ ràng: thực chất chúng tôi đang giao tài liệu điều tra thật cho một dịch vụ bên ngoài. Với sự cố, điều này đặc biệt nhạy cảm: trong tài liệu có thể có họ tên, chức danh, thông tin y tế, bản tường trình, ảnh chụp và thông tin nội bộ của doanh nghiệp.

Càng sử dụng công cụ, chúng tôi càng thấy rõ: sự tiện lợi không thể là lý do để đưa dữ liệu không cần thiết ra bên ngoài.

Xem phụ lục prompt: Prompt 1 — phiên bản an toàn của tác tử đám mây, chỉ làm việc với tài liệu đã được ẩn danh hóa từ trước.

Phương pháp luận chặt chẽ hơn — và điều đó thay đổi yêu cầu đối với AI

Song song đó, chính phương pháp luận điều tra nội bộ của doanh nghiệp cũng phát triển. Với tôi, đây là điểm quan trọng: không thể trao cho AI quyền “tự nghĩ ra cách điều tra”. Phải có phương pháp luận trước, rồi mới xây dựng công cụ số dựa trên nó.

Theo phương pháp luận hiện hành, mục tiêu chính của hội đồng không phải là tìm người có lỗi, mà là xây dựng những biện pháp hiệu quả nhất để loại trừ hoặc giảm khả năng lặp lại sự việc tương tự. Nếu trong chuỗi sự kiện có hành động của con người, cần đi xa hơn và làm rõ vì sao hành động đó lại có thể xảy ra hoặc được coi là chấp nhận được.

Cuộc điều tra được xây dựng theo logic rào chắn bảo vệ: nguồn nguy hiểm → sự kiện không mong muốn → hậu quả; rào chắn phòng ngừa và rào chắn ứng phó được xem xét riêng. Ở giai đoạn phân tích thông tin, hội đồng lập dòng thời gian và xác định các yếu tố then chốt. Tiếp theo là xây dựng cây nguyên nhân, dẫn từ nguyên nhân trực tiếp và trung gian đến nguyên nhân gốc rễ mang tính hệ thống.

Trong những vụ việc đơn giản hơn, chuỗi câu hỏi “Tại sao?” có thể ngắn. Trong một sự việc phức tạp, nó phân nhánh và trở thành một cây nguyên nhân hoàn chỉnh. Logic rào chắn của mô hình “nơ con bướm” giúp kiểm tra riêng biệt: vì sao sự kiện lại xảy ra và vì sao hậu quả lại đúng như vậy.

Chính trình tự này về sau trở thành bộ khung cho ứng dụng cục bộ của chúng tôi.

Xem Prompt 2–6: dòng thời gian và yếu tố then chốt → câu hỏi và mâu thuẫn → rào chắn → cây nguyên nhân → biện pháp.

Phương án thứ hai: che giấu dữ liệu thủ công

Giai đoạn tiếp theo an toàn hơn nhiều, dù khá bất tiện. Trước khi tải tài liệu lên tác tử đám mây, chúng tôi thay thủ công họ tên và các giá trị nhạy cảm khác: “Người lao động 1”, “Người lao động 2”, “Người quản lý 1”, “Bộ phận 1” và cứ thế tiếp tục.

Về bảo mật, đây đã là một bước tiến. Tác tử thấy được logic của sự cố nhưng không thấy họ tên thật. Sau khi phân tích xong, chúng tôi phải thay các ký hiệu trở lại bằng tay — thường là qua chức năng tìm kiếm Ctrl+F.

Khi chỉ có hai, ba người liên quan, quy trình này còn chấp nhận được. Nhưng khi cuộc điều tra có nhiều bản tường trình, nhân chứng, văn bản và họ tên lặp lại, việc che giấu thủ công rồi khôi phục ngược lại trở thành một khối việc riêng và tạo ra nguy cơ sai sót.

Phương án thứ ba: công cụ che giấu dữ liệu cục bộ và bài toán riêng về âm thanh

Khi đã có kỹ năng vibe coding, chúng tôi thay thao tác thủ công bằng công cụ che giấu dữ liệu cục bộ mà tôi đã giới thiệu trong bài đầu tiên của loạt bài. Tài liệu Word được xử lý ngay trên máy tính và được gán các ký hiệu quy ước, còn khóa khôi phục được lưu riêng. Khóa được bảo vệ bằng mật khẩu và không được chuyển cho tác tử.

Sau đó, chỉ các bản tường trình và tài liệu khác đã được che giấu mới được gửi lên AI đám mây. Kết quả nhận về được đưa trở lại máy tính và khôi phục cục bộ. Chính quy trình này hiện là quy trình vận hành của chúng tôi: công cụ che giấu cục bộ → tác tử điều tra đã được thiết lập → khôi phục dữ liệu gốc cục bộ. Nó đã cho phép tận dụng thế mạnh của mô hình đám mây mà không phải giao cho mô hình họ tên gốc và khóa khôi phục.

Nhưng vẫn còn một khâu dễ tổn thương nữa — các bản ghi âm. Ghi lại lời tường trình và các cuộc phỏng vấn bằng giọng nói rất tiện, nhưng để phân tích thì trước hết phải chuyển chúng thành văn bản. Trước đây, việc này được làm bằng các dịch vụ trực tuyến và ứng dụng di động riêng. Về sau, tính năng chuyển giọng nói thành văn bản có sẵn ngay trong các dịch vụ AI lớn. Điều đó tiện lợi, nhưng bản ghi gốc chứa giọng nói của con người vẫn bị đưa ra bên ngoài.

Vì vậy, chúng tôi làm thêm một công cụ nữa — công cụ chuyển giọng nói thành văn bản cục bộ. Nó chạy Whisper ngay trên máy tính. Trong các thử nghiệm của chúng tôi, chất lượng chuyển văn bản hoàn toàn tương đương với các phương án đám mây quen thuộc, trong khi bản ghi âm gốc không rời khỏi máy tính. Sau khi chuyển thành văn bản cục bộ, có thể che giấu dữ liệu trong văn bản rồi mới — khi cần — chuyển cho tác tử điều tra đang vận hành.

Chuỗi công cụ của giai đoạn này: chuyển giọng nói thành văn bản cục bộ → công cụ che giấu cục bộ → tác tử đám mây. Để phân tích tài liệu, xem Prompt 1–6.

Phương án thứ tư: hệ thống ngoại tuyến đã được xây dựng — giờ chúng tôi đang thử nghiệm nó

Đến đây, một câu hỏi khác nảy sinh. Nếu việc chuyển giọng nói thành văn bản, đọc tài liệu và mô hình đều đã chạy được cục bộ, tại sao không gom tất cả vào một môi trường bảo mật duy nhất? Thế là hệ thống điều tra ngoại tuyến thử nghiệm ra đời. Hệ thống đã được phát triển và đang hoạt động, nhưng hiện nay chúng tôi chủ động coi nó là bản thử nghiệm: kiểm tra trên các tình huống huấn luyện và tình huống đã ẩn danh hóa, đối chiếu kết quả với công việc của hội đồng và tìm các vòng lặp tiếp theo để quy trình nhanh hơn, tiện hơn và ổn định hơn.

Nhiệm vụ đặt ra là: tạo một nơi làm việc thống nhất cho hội đồng, nơi có thể tải lên tài liệu hướng dẫn phương pháp luận, thông tin ban đầu, bản tường trình, tệp Word và PDF, bản ghi âm, ảnh chụp và sơ đồ; chuyển lời nói và tài liệu thành văn bản ngay trên máy; đi qua từng giai đoạn của phương pháp luận và nhận được bản dự thảo đầu tiên của báo cáo Word có thể chỉnh sửa.

Gói gọn trong một câu thì nghe có vẻ đơn giản. Trên thực tế, số vòng lặp là rất nhiều. Nhận dạng giọng nói cục bộ không chạy được ngay, sau đó phải xử lý các bản PDF scan, hình ảnh, khối tài liệu lớn, mô hình cục bộ, dòng thời gian, nguyên nhân và văn bản cuối cùng. Cách phát triển vẫn giống như trong các dự án khác của chúng tôi: một thay đổi → chạy thử → kết quả hoặc ảnh chụp lỗi → vòng lặp tiếp theo với ChatGPT.

Kết quả là một hệ thống cục bộ với giao diện trình duyệt và môi trường AI cục bộ riêng. Hệ thống đã chuyển giọng nói thành văn bản tốt, đọc các tài liệu đã chuẩn bị và tạo ra bản dự thảo điều tra có cấu trúc. Nhiệm vụ của chúng tôi lúc này không phải là tuyên bố nó là “sản phẩm hoàn chỉnh”, mà là bình tĩnh thử nghiệm, so sánh kết quả và cải thiện logic làm việc. Để chạy một mô hình cục bộ đầy đủ và xử lý nhanh khối lượng dữ liệu lớn, nên có một máy tính cấu hình đủ mạnh.

Xem Prompt 8 — prompt tổng để vibe coding nơi làm việc cục bộ của hội đồng.

Phiên bản ngoại tuyến thử nghiệm đã làm được gì

Trong phiên bản ngoại tuyến thử nghiệm, toàn bộ chu trình đã được xây dựng xoay quanh phương pháp luận, chứ không phải xoay quanh một cuộc trò chuyện thông thường với AI.

Trước tiên, hội đồng ghi nhận thông tin ban đầu: chuyện gì đã xảy ra, nguồn nguy hiểm, sự kiện không mong muốn, hậu quả, những người liên quan, kết quả khám nghiệm hiện trường. Tiếp theo là lập kế hoạch: cần làm rõ những câu hỏi nào, phỏng vấn ai, cần thu thập những văn bản và kết quả giám định nào.

Trong mục tài liệu có thể tải lên tệp DOCX và PDF dạng văn bản. Bản scan và ảnh chụp có thể nhận dạng cục bộ; sơ đồ và hình ảnh được lưu trong hồ sơ vụ việc, và mô hình có thể đề xuất mô tả các chi tiết nhìn thấy được. Âm thanh và video được chuyển thành văn bản cục bộ. Cũng có thể ghi âm cuộc phỏng vấn trực tiếp từ micro rồi nhận bản chép lời.

Sau khi tài liệu được kiểm tra, ứng dụng giúp dựng dòng thời gian. AI đề xuất các sự kiện và trích dẫn, nhưng quyết định đưa một mục vào hay không là do hội đồng. Các yếu tố then chốt được đánh dấu riêng.

Khối tiếp theo là rào chắn bảo vệ và nguyên nhân. Hội đồng kiểm tra các rào chắn phòng ngừa và ứng phó, xây dựng hai nhánh xuất phát: vì sao sự kiện không mong muốn xảy ra và vì sao lại dẫn đến hậu quả như vậy. Các nguyên nhân do AI đề xuất vẫn chỉ là giả thuyết cho đến khi hội đồng xác nhận.

Sau nguyên nhân là các biện pháp: biện pháp gắn với nguyên nhân nào, ai chịu trách nhiệm, thời hạn, kết quả nào có thể kiểm chứng, có cần rào chắn tạm thời không, biện pháp có cần áp dụng rộng hơn một khu vực hay không.

Và chỉ sau đó mới lập bản dự thảo báo cáo. Ứng dụng có thể tạo bản dự thảo Word đầu tiên theo cấu trúc của tài liệu hướng dẫn phương pháp luận, đưa vào dòng thời gian, cây nguyên nhân, rào chắn, danh mục tài liệu và các phụ lục.

Xem Prompt 2 — dòng thời gian; Prompt 3 — mâu thuẫn và dữ liệu còn thiếu; Prompt 4 — rào chắn; Prompt 5 — cây nguyên nhân; Prompt 6 — biện pháp; Prompt 7 — dự thảo báo cáo cuối cùng.

AI cục bộ làm gì — và những gì nó không được làm

Ở đây điều quan trọng là không đánh giá quá cao khả năng tự động hóa. AI đọc các văn bản đã được kiểm tra theo từng đoạn, đề xuất dòng thời gian, câu hỏi, rào chắn, giả thuyết nguyên nhân và các phương án biện pháp. Nó có thể phát hiện mâu thuẫn giữa hai bản tường trình hoặc nhận ra dòng thời gian đang thiếu một khoảng thời gian quan trọng.

Nhưng một trích dẫn từ tài liệu chỉ xác nhận rằng những lời đó thực sự có trong tài liệu. Nó không chứng minh lời khai là đúng sự thật. Văn bản được nhận dạng có thể chứa lỗi. Sơ đồ có thể bị hiểu sai. Mối quan hệ nhân quả có thể chỉ là giả thuyết.

Vì vậy, ứng dụng được xây dựng theo nguyên tắc: AI đề xuất — hội đồng chấp nhận, bác bỏ hoặc chỉnh sửa. Nguyên nhân không tự động trở thành nguyên nhân đã được xác nhận. Người chịu trách nhiệm và thời hạn không do mô hình chỉ định. Bản Word chính là bản dự thảo làm việc đầu tiên, chứ không phải văn bản “cứ thế mà ký”.

Điều này đặc biệt quan trọng vì báo cáo nội bộ không thay thế các văn bản theo quy định của pháp luật và các thủ tục đã được ban hành. Trách nhiệm đối với cuộc điều tra vẫn thuộc về hội đồng.

Xem Prompt 9 — kiểm soát chất lượng, bảo mật và giới hạn của tự động hóa trước khi sử dụng kết quả.

Bảo mật trở thành một phần của kiến trúc, chứ không còn là một hướng dẫn riêng

Với công tác điều tra, vấn đề bảo mật không thể để “tính sau”. Bản thân phương pháp luận xếp tài liệu điều tra nội bộ vào loại tài liệu chỉ dùng nội bộ và có yêu cầu riêng về việc bảo vệ dữ liệu cá nhân khi tạo và chuyển giao tệp.

Trong phiên bản ngoại tuyến thử nghiệm, tài liệu hồ sơ, bản chép lời, kết quả phân tích và tệp Word đều nằm lại trên máy tính. Mô hình cục bộ hoạt động qua địa chỉ loopback, và sau khi đã chuẩn bị xong các mô hình cần thiết, phiên làm việc với hồ sơ có thể tiến hành mà không cần kết nối internet bên ngoài.

Nhưng ở đây cũng không có phép màu. Làm việc cục bộ không đồng nghĩa với ẩn danh hóa tự động. Nếu đưa họ tên và thông tin y tế vào hồ sơ, chúng sẽ nằm lại trên máy tính này và trong các phụ lục của hồ sơ. Vì vậy vẫn cần các biện pháp an toàn thông tin thông thường: tài khoản được bảo vệ, phân quyền truy cập, quy tắc lưu trữ, sao lưu dự phòng và, khi cần, che giấu dữ liệu bổ sung.

Nói cách khác, quá trình phát triển của chúng tôi không kết thúc bằng khẩu hiệu “mọi thứ ngoại tuyến nghĩa là mọi thứ an toàn”. Nói đúng hơn: chúng tôi đã loại bỏ việc chuyển tài liệu ra ngoài một cách không cần thiết và giữ quyền kiểm soát dữ liệu ở đúng nơi của nó — bên trong doanh nghiệp.

Hiện nay chúng tôi dùng gì

Hiện nay, trên thực tế chúng tôi có hai quy trình. Quy trình thứ nhất là quy trình vận hành: che giấu dữ liệu trong tài liệu ngay trên máy, chuyển bản sao đã ẩn danh hóa cho tác tử điều tra đã được thiết lập, rồi khôi phục dữ liệu gốc trong kết quả nhận được, cũng ngay trên máy. Chính cách làm này đã có thể dùng trong công việc thực tế.

Quy trình thứ hai là quy trình thử nghiệm: một hệ thống hoàn toàn ngoại tuyến, tự chuyển âm thanh thành văn bản cục bộ, đọc tài liệu, giúp dựng dòng thời gian, rào chắn và nguyên nhân, và tạo bản dự thảo báo cáo đầu tiên. Hệ thống đã hoạt động, nhưng chúng tôi vẫn tiếp tục kiểm tra và cải thiện nó. Với chúng tôi, đây là điều mang tính nguyên tắc: không thể coi một dự án thí điểm là hệ thống sản xuất hoàn thiện chỉ vì nó trông đẹp mắt.

Quy trình vận hành: công cụ che giấu dữ liệu → tác tử AI điều tra đã được thiết lập → khôi phục dữ liệu gốc.

Quy trình thử nghiệm: nơi làm việc hoàn toàn cục bộ của hội đồng → kiểm tra và các vòng lặp tiếp theo.

Bước tiếp theo — Fire, môi trường AI doanh nghiệp bảo mật

Song song đó, bộ phận IT của Tập đoàn đang phát triển AI nội bộ Fire trong môi trường doanh nghiệp Collab. Với chúng tôi, đây là giai đoạn tiếp theo hợp logic: chuyển logic phương pháp luận của trợ lý hội đồng sang môi trường máy chủ doanh nghiệp được bảo mật, nơi không cần phải chọn giữa sức mạnh của một mô hình lớn và các yêu cầu về bảo mật.

Chúng tôi không xem Fire là một “điều tra viên tự động”, mà là thêm một môi trường cho cùng một nguyên tắc: tài liệu ở lại bên trong hạ tầng được bảo vệ, AI giúp hội đồng phân tích dòng thời gian, rào chắn, mâu thuẫn và nguyên nhân, còn quyết định vẫn do con người đưa ra.

Trước khi chuyển đổi, cần kiểm tra các khả năng kỹ thuật của Fire: làm việc với tài liệu và âm thanh, dung lượng ngữ cảnh, phân quyền truy cập, nhật ký, lưu trữ dữ liệu và xuất kết quả. Tức là ở đây, một lần nữa, chúng tôi xuất phát từ phương pháp luận và yêu cầu bảo vệ thông tin, chứ không phải từ mong muốn dùng bằng mọi giá một mô hình mới nào đó.

Xem video: toàn bộ chu trình điều tra cục bộ

Trong bài viết này, tôi cố ý không nhồi vào hàng chục ảnh chụp màn hình na ná nhau. Một đoạn ghi màn hình dài ba phút cho thấy rõ hơn các thành phần liên kết với nhau như thế nào, đâu là việc con người thực sự làm và đâu là việc chương trình làm.

Ảnh chụp màn hình chỉ cần ở những chỗ phải dừng lại ở kiến trúc: các loại tài liệu, dòng thời gian, nguyên nhân, biện pháp và tệp Word cuối cùng. Phần cơ chế còn lại nên xem qua video — video nằm ở cuối bài.

Tiết kiệm thời gian ở đâu

Điều tra sự cố dù sao vẫn cần con người: khám nghiệm hiện trường, phỏng vấn người liên quan, thu thập văn bản, thảo luận các dữ kiện, đưa ra quyết định. Không thể tự động hóa bản chất công việc của hội đồng.

Nhưng có thể loại bỏ phần lớn công việc giấy tờ thường ngày: gõ lại bản ghi âm, tổng hợp các bản tường trình, dò tìm thủ công những chỗ lệch về thời gian, chuyển trích dẫn vào dòng thời gian, sắp xếp sơ bộ các rào chắn, trình bày cây nguyên nhân, chuẩn bị danh sách biện pháp dự kiến và tập hợp bản dự thảo báo cáo đầu tiên.

Và ở đây, với tôi, hiệu quả chính không nằm ở việc cắt giảm số chuyên gia. Ngược lại: nếu chuyên gia bớt thời gian cho công việc giấy tờ mang tính cơ học, họ sẽ có thêm thời gian cho điều mà cuộc điều tra hướng tới — trò chuyện với con người, làm việc tại hiện trường, kiểm tra rào chắn và giúp các nhà quản lý ngăn sự việc tái diễn.

Kết quả cuối cùng

Sau vài năm, hành trình này khá tiêu biểu: tác tử đám mây mở → che giấu dữ liệu thủ công → công cụ che giấu và khôi phục cục bộ → chuyển giọng nói thành văn bản cục bộ → hệ thống ngoại tuyến thử nghiệm → bước tiếp theo sang Fire, môi trường AI doanh nghiệp bảo mật.

Đồng thời, công cụ làm việc hiện nay không phải là phiên bản ngoại tuyến thử nghiệm, mà là quy trình che giấu dữ liệu đã được kiểm chứng: tài liệu gốc ở lại với chúng tôi, tác tử chỉ nhận phiên bản đã ẩn danh hóa, còn việc khôi phục được thực hiện cục bộ. Hệ thống ngoại tuyến hiện đang được chúng tôi thử nghiệm và hoàn thiện dần từng bước.

Thay đổi quan trọng nhất thậm chí không nằm ở kỹ thuật. Chúng tôi đã thôi hỏi AI “ai có lỗi?” và bắt đầu hỏi một câu khác: “còn thiếu dữ liệu gì, những rào chắn nào đã không phát huy tác dụng, vì sao chúng không phát huy tác dụng và những biện pháp nào thực sự giảm được nguy cơ tái diễn?”

Chính ở vai trò này, AI hữu ích trong điều tra: không phải thẩm phán hay chủ tịch hội đồng, mà là một nhà phân tích thứ hai nhanh nhạy, giúp con người làm việc sâu hơn với các dữ kiện.

Và một điều nữa: đừng quên trí tuệ tự nhiên

Các mô hình càng mạnh, việc không giao phó tư duy của chính mình cho chúng càng quan trọng. Trí tuệ nhân tạo có ích khi nó tăng cường trí tuệ tự nhiên: giúp nhanh chóng nhìn ra mối liên hệ, kiểm tra giả thuyết, soạn bản nháp và giải phóng thời gian để trò chuyện với con người và làm việc tại hiện trường.

Vì vậy, với tôi, con đường đúng đắn là không chỉ làm người dùng những nút bấm có sẵn, mà trở thành người tạo ra giải pháp mới: hiểu phương pháp luận, định hình kiến trúc, kiểm tra kết quả, sửa lỗi và tự mình trở nên mạnh hơn cùng với công cụ.

Cần sử dụng AI, nhưng cũng cần vận dụng và phát triển trí tuệ tự nhiên của chính mình không kém. Và nếu sự kết hợp này giúp điều tra sự việc sâu hơn, rút ra bài học tốt hơn và ngăn chặn sự việc tái diễn — nghĩa là công nghệ thực sự đang phục vụ an toàn.

Các prompt kèm theo bài viết

Quy trình vận hành có che giấu dữ liệu → hệ thống ngoại tuyến thử nghiệm → bước tiếp theo sang Fire, môi trường AI doanh nghiệp bảo mật

Tình trạng hiện tại: trong công việc thực tế đang sử dụng quy trình “công cụ che giấu cục bộ → tác tử đám mây đã được thiết lập → khôi phục dữ liệu gốc cục bộ”. Hệ thống hoàn toàn ngoại tuyến đã được phát triển nhưng đang ở giai đoạn thử nghiệm và cải tiến. Fire được xem là giai đoạn tiếp theo trong môi trường doanh nghiệp bảo mật.

Prompt 1. Tác tử đang vận hành: chỉ dùng tài liệu đã ẩn danh hóa

Liên hệ với bài viết: các mục “Phương án thứ ba” và “Hiện nay chúng tôi dùng gì”. Đây là quy trình đang vận hành sau khi che giấu dữ liệu cục bộ.

Bạn là trợ lý phân tích của hội đồng điều tra nội bộ sự cố trong lĩnh vực an toàn vệ sinh lao động và an toàn công nghiệp.

QUY TRÌNH LÀM VIỆC:
Tài liệu gốc trước tiên được che giấu dữ liệu cục bộ. Bạn chỉ nhận các bản sao đã ẩn danh hóa. Sau khi bạn làm xong, kết quả được khôi phục dữ liệu gốc cục bộ bằng một khóa và mật khẩu riêng mà bạn không có.

QUAN TRỌNG:
- chỉ làm việc với tài liệu đã được ẩn danh hóa từ trước;
- không cố khôi phục họ tên, bộ phận, địa chỉ hoặc các giá trị bị ẩn khác;
- không dùng internet và các dữ kiện bên ngoài nếu chúng không được cung cấp riêng;
- không xác định người có lỗi;
- không gọi giả thuyết là sự thật đã được xác lập;
- không thay thế quyết định của hội đồng.

Mục tiêu: giúp hội đồng hệ thống hóa tài liệu và kiểm tra tính đầy đủ của cuộc điều tra.

Với mỗi kết luận, hãy phân loại:
FACT — được tài liệu xác nhận trực tiếp;
ASSUMPTION — giả định có cơ sở;
CONFLICT — mâu thuẫn giữa các tài liệu;
GAP — thông tin còn thiếu;
QUESTION — câu hỏi cần được làm rõ;
HYPOTHESIS — nguyên nhân có thể có, cần được xác nhận.

Trình tự:
1. Lập danh mục các tài liệu đã nhận.
2. Chỉ trích xuất những dữ kiện có thể xác nhận được, kèm nguồn.
3. Lập dòng thời gian sơ bộ.
4. Chỉ ra các mâu thuẫn và khoảng trống.
5. Soạn các câu hỏi bổ sung cho hội đồng.
6. Sau khi dòng thời gian được xác nhận, đề xuất phân tích rào chắn.
7. Chỉ đưa ra nguyên nhân dưới dạng giả thuyết cho đến khi hội đồng quyết định.
8. Chỉ gắn biện pháp với các nguyên nhân đã được xác nhận.

Trong mọi bảng, hãy ghi nguồn: số thứ tự tài liệu, văn bản/tệp và trích dẫn ngắn hoặc vị trí chính xác làm căn cứ cho kết luận.

Prompt 2. Dòng thời gian sự việc và các yếu tố then chốt

Liên hệ với bài viết: phần về dòng thời gian trong tác tử đang vận hành và trong hệ thống ngoại tuyến thử nghiệm.

Tôi cung cấp nội dung đã được kiểm tra của các tài liệu về sự cố.

Hãy lập DỰ THẢO dòng thời gian.

Quy tắc:
1. Không thêm sự kiện không có trong tài liệu.
2. Nếu thời gian là chính xác — ghi rõ là chính xác.
3. Nếu thời gian là ước lượng — đánh dấu “ước tính”.
4. Nếu hai nguồn đưa ra thời gian hoặc trình tự khác nhau — không lặng lẽ chọn một phương án; hãy chỉ ra CONFLICT.
5. Với mỗi dòng, ghi: ngày/giờ; sự kiện hoặc điều kiện; nguồn; trạng thái FACT / ASSUMPTION / CONFLICT; vì sao điều này quan trọng.
6. Đề xuất riêng danh sách các yếu tố then chốt: những sự kiện/điều kiện mà nếu không có thì sự kiện không mong muốn hoặc mức độ nghiêm trọng của hậu quả có lẽ đã khác.
7. Không coi các yếu tố then chốt là đã được phê duyệt cho đến khi hội đồng quyết định.

Cuối cùng, hãy đưa ra:
A. dự thảo dòng thời gian;
B. danh sách mâu thuẫn;
C. danh sách dữ liệu còn thiếu;
D. dự thảo các yếu tố then chốt để hội đồng thảo luận.

Prompt 3. Mâu thuẫn, khoảng trống và kế hoạch phỏng vấn bổ sung

Liên hệ với bài viết: các phần về lập kế hoạch, thu thập tài liệu và vai trò của AI như nhà phân tích thứ hai.

Dựa trên tài liệu và dự thảo dòng thời gian, hãy chuẩn bị phiếu làm việc cho hội đồng.

Cần:
1. Tìm các mâu thuẫn giữa bản tường trình, văn bản, thời gian và dữ liệu kỹ thuật.
2. Không coi sự khác biệt trong cách diễn đạt là nói dối khi không có bằng chứng.
3. Với mỗi mâu thuẫn, ghi: nguồn A; nguồn B; khác biệt cụ thể là gì; cần kiểm tra điều gì.
4. Soạn câu hỏi cho các cuộc phỏng vấn bổ sung.
5. Câu hỏi phải mở và trung lập, không gợi ý câu trả lời.
6. Lập riêng danh sách văn bản, số đo, giám định, ảnh chụp hoặc sơ đồ có thể lấp khoảng trống.
7. Đánh dấu những câu hỏi mang tính then chốt để xác định tình tiết, rào chắn bảo vệ, nguyên nhân và mức độ nghiêm trọng của hậu quả.

Không kết luận lời khai không đáng tin chỉ vì có mâu thuẫn.

Prompt 4. Logic rào chắn và mô hình “nơ con bướm”

Liên hệ với bài viết: phần về logic rào chắn và bước chuyển sang phân tích nguyên nhân.

Hãy sử dụng dòng thời gian và các yếu tố then chốt đã được hội đồng xác nhận.

Hãy lập DỰ THẢO phân tích rào chắn.

1. Các nguồn nguy hiểm.
2. Sự kiện không mong muốn.
3. Hậu quả.
4. Rào chắn phòng ngừa: rào chắn nào lẽ ra phải ngăn chặn sự kiện/tiếp xúc; rào chắn đó có tồn tại không; có sẵn sàng không; có được áp dụng không; có phát huy tác dụng không; nguồn xác nhận.
5. Rào chắn ứng phó: rào chắn nào lẽ ra phải ngăn chặn hậu quả hoặc giảm mức độ nghiêm trọng; rào chắn đó có tồn tại không; có phát huy tác dụng không; nguồn xác nhận.
6. Với mỗi rào chắn không có hoặc không hiệu quả, hãy đặt câu hỏi “Tại sao?”.

Không tự động gọi việc thiếu rào chắn là nguyên nhân gốc rễ.
Không tự nghĩ ra các rào chắn không có trong phương pháp luận, văn bản hoặc logic công nghệ mà không đánh dấu HYPOTHESIS.

Đầu ra là bảng để hội đồng thảo luận, không phải kết luận đã được phê duyệt.

Prompt 5. Cây nguyên nhân và nguyên nhân gốc rễ

Liên hệ với bài viết: mục “Phương pháp luận chặt chẽ hơn” và khối nguyên nhân.

Đầu vào:
- dòng thời gian đã được xác nhận;
- các yếu tố then chốt;
- phân tích rào chắn;
- quyết định của hội đồng về các dữ kiện đã được xác nhận.

Hãy xây dựng DỰ THẢO cây nguyên nhân.

Điểm xuất phát: “Sự kiện không mong muốn + hậu quả”.
Hai nhánh đầu tiên:
A. Vì sao sự kiện không mong muốn xảy ra?
B. Vì sao lại dẫn đến hậu quả như vậy / vì sao mức độ nghiêm trọng lại như vậy?

Tiếp theo:
1. Với mỗi nút, hỏi “Tại sao?” bao nhiêu lần tùy theo mức cần thiết để đi tới nguyên nhân hệ thống.
2. Gắn mỗi nguyên nhân với câu hỏi cấp trên của nó.
3. Mỗi yếu tố then chốt phải được phản ánh trong cây hoặc được giải thích riêng là đã loại trừ.
4. Không coi hành động/sai sót của con người là nguyên nhân gốc rễ. Tiếp tục phân tích: vì sao hành động đó có thể xảy ra hoặc được coi là chấp nhận được.
5. Chỉ đề xuất nguyên nhân gốc rễ nếu nó mô tả một khiếm khuyết cụ thể của quy trình/hệ thống; có thể khắc phục được; nằm trong phạm vi kiểm soát của doanh nghiệp/Tập đoàn; cho phép đề xuất một biện pháp cụ thể.
6. Cấm các cách diễn đạt chung chung không được giải thích rõ: “văn hóa yếu kém”, “bất cẩn cá nhân”, “tổ chức kém”, “thiếu sót trong đào tạo”.

Với mỗi nút:
- nội dung diễn đạt;
- loại: trực tiếp / trung gian / ứng viên nguyên nhân gốc rễ;
- các nguồn xác nhận;
- các yếu tố then chốt liên quan;
- trạng thái FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

Không xác nhận nguyên nhân gốc rễ thay cho hội đồng.

Prompt 6. Biện pháp khắc phục và phòng ngừa

Liên hệ với bài viết: phần về biện pháp và việc tiết kiệm thời gian khi chuẩn bị bản dự thảo đầu tiên.

Chỉ sử dụng những nguyên nhân mà hội đồng đã quyết định đưa vào danh sách để xây dựng biện pháp.

Với mỗi nguyên nhân, đề xuất 2–4 phương án biện pháp.

Với mỗi phương án, nêu rõ:
- loại bỏ nguyên nhân cụ thể nào hoặc tăng cường rào chắn nào;
- loại: kỹ thuật / tổ chức / đào tạo / kiểm soát / khác;
- kết quả dự kiến có thể kiểm chứng;
- cách kiểm tra hiệu quả;
- phạm vi áp dụng: nơi xảy ra sự việc / các cơ sở tương tự / doanh nghiệp / Tập đoàn;
- có cần biện pháp bảo vệ tạm thời trước khi thực hiện biện pháp lâu dài không;
- các rủi ro phát sinh có thể có;
- cần dữ liệu gì để xác định thời hạn và người chịu trách nhiệm.

Không điền họ tên người chịu trách nhiệm và thời hạn cụ thể khi chưa có quyết định của hội đồng.
Không đề xuất biện pháp kiểu “tổ chức hướng dẫn an toàn đột xuất” như một giải pháp vạn năng nếu nó không loại bỏ được nguyên nhân đã xác định.
Đánh dấu riêng các biện pháp chỉ tăng cường kiểm soát mà không loại bỏ nguyên nhân gốc rễ.

Prompt 7. Dự thảo báo cáo cuối cùng theo phương pháp luận

Liên hệ với bài viết: phần về việc tạo tệp Word và nguyên tắc “bản dự thảo đầu tiên, không phải văn bản để ký”.

Hãy chuẩn bị DỰ THẢO nội dung báo cáo nội bộ chỉ dựa trên các nội dung đã được hội đồng phê duyệt.

Sử dụng:
- phiếu thông tin sự cố;
- dòng thời gian đã được xác nhận;
- danh sách các yếu tố then chốt;
- phân tích rào chắn đã được phê duyệt;
- cây nguyên nhân cuối cùng;
- danh sách nguyên nhân đã được phê duyệt;
- các biện pháp đã được thống nhất;
- danh mục tài liệu.

Không đưa vào phần kết luận như dữ kiện: những giả thuyết chưa được xác nhận, những phiên bản còn tranh cãi mà không có đánh dấu, những kết luận không có nguồn.

Cấu trúc:
1. Thông tin tóm tắt và tình tiết.
2. Tài liệu và phương pháp thu thập thông tin.
3. Dòng thời gian.
4. Các yếu tố then chốt.
5. Rào chắn bảo vệ.
6. Phân tích nguyên nhân.
7. Nguyên nhân gốc rễ.
8. Biện pháp khắc phục và phòng ngừa.
9. Phụ lục / danh mục tài liệu.

Khi có thể, hãy giữ tham chiếu đến tài liệu làm căn cứ bên cạnh mỗi kết luận quan trọng.
Ở đầu văn bản, ghi rõ: “DỰ THẢO. Cần được hội đồng kiểm tra và thống nhất”.
Không đưa ra kết luận về lỗi của bất kỳ ai.

Prompt 8. Prompt tổng cho hệ thống ngoại tuyến thử nghiệm

Liên hệ với bài viết: mục “Hệ thống ngoại tuyến đã được xây dựng — giờ chúng tôi đang thử nghiệm nó”.

Tôi không phải lập trình viên. Hãy giúp tôi tạo một ứng dụng cục bộ THỬ NGHIỆM để điều tra nội bộ sự cố theo phương pháp luận của doanh nghiệp. Mục tiêu của giai đoạn này là thí điểm và kiểm tra chất lượng, chứ không phải tự động đưa vào vận hành công nghiệp.

Làm việc theo từng bước. Ở mỗi bước:
1. giải thích chúng ta đang làm gì và để làm gì;
2. đưa ra một hành động hoặc một tệp/bản vá hoàn chỉnh;
3. chờ kết quả hoặc ảnh chụp màn hình của tôi;
4. kiểm tra nó;
5. chỉ sau đó mới chuyển sang bước tiếp theo.

KIẾN TRÚC MỤC TIÊU
- Windows 10/11;
- backend cục bộ trên 127.0.0.1 và giao diện trình duyệt;
- sau khi chuẩn bị mô hình một lần, làm việc với tài liệu hồ sơ mà không cần internet bên ngoài;
- tính đến việc chạy trên máy tính làm việc cấu hình mạnh; với máy yếu thì đề xuất mô hình nhẹ hơn, nhưng không che giấu việc giảm chất lượng/tốc độ;
- lưu trữ hồ sơ cục bộ;
- gói lưu trữ hồ sơ kèm tổng kiểm tra;
- lịch sử phiên bản;
- không bắt buộc gửi tài liệu tới bất kỳ API bên ngoài nào.

TÀI LIỆU
- DOCX: đoạn văn, bảng, đầu trang và chân trang;
- PDF có lớp văn bản;
- PDF scan / hình ảnh — nhận dạng cục bộ;
- sơ đồ / ảnh chụp — lưu bản gốc và chỉ đề xuất mô tả dưới dạng bản nháp;
- âm thanh / video — chuyển thành văn bản cục bộ;
- ghi âm từ micro;
- nhập và chỉnh sửa thủ công;
- bắt buộc đánh dấu “đã đối chiếu với bản gốc” trước khi dùng văn bản cho phân tích AI.

MÔ HÌNH CỤC BỘ
- LLM qua một công cụ chạy cục bộ (ví dụ Ollama);
- mô hình giọng nói đa ngôn ngữ Whisper;
- khi cần, một mô hình vision cục bộ;
- ứng dụng không được âm thầm tải mô hình xuống trong quá trình điều tra.

PHƯƠNG PHÁP LUẬN / CÁC GIAI ĐOẠN
1. Thông tin ban đầu.
2. Kế hoạch của hội đồng.
3. Thu thập tài liệu.
4. Dòng thời gian và các yếu tố then chốt.
5. Rào chắn và nguyên nhân.
6. Biện pháp.
7. Báo cáo.

QUY TẮC CHO AI
- AI chỉ đề xuất.
- Mỗi kết luận được lưu kèm nguồn và trích dẫn.
- Phân biệt FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Nguyên nhân là giả thuyết cho đến khi hội đồng xác nhận.
- Mô hình không tự chỉ định người chịu trách nhiệm và thời hạn.
- Hội đồng phải có khả năng chấp nhận, bác bỏ hoặc chỉnh sửa từng đề xuất.
- Tệp Word cuối cùng là bản dự thảo có thể chỉnh sửa.
- Báo cáo phải gồm cây nguyên nhân, rào chắn, danh mục tài liệu và phụ lục.

BẢO MẬT
- không dùng CDN và không có telemetry gửi ra ngoài;
- các kết nối mạng trong quá trình điều tra chỉ qua loopback;
- cho người dùng thấy rằng làm việc cục bộ không đồng nghĩa với ẩn danh hóa tự động;
- không lưu thông tin bí mật ở dạng mở trong mã phía máy khách;
- có chức năng xóa hồ sơ, sao lưu và chuyển hồ sơ sang máy khác.

Hãy bắt đầu với cấu trúc thư mục, định dạng dữ liệu hồ sơ và mô hình mối đe dọa. Không viết mã cho đến khi tôi xác nhận.

TRẠNG THÁI THÍ ĐIỂM
- đánh dấu rõ phiên bản là “THỬ NGHIỆM / THÍ ĐIỂM”;
- thêm bộ tình huống huấn luyện dùng làm đối chứng;
- với mỗi tình huống, so sánh kết quả của AI với kết luận của con người/hội đồng;
- ghi nhật ký các lỗi phát hiện được và các vòng lặp;
- không gọi hệ thống là sẵn sàng vận hành công nghiệp trước khi kết thúc thử nghiệm.

Prompt 9. Rà soát hệ thống ngoại tuyến thí điểm

Liên hệ với bài viết: các phần về giới hạn của tự động hóa, bảo mật và tình trạng thử nghiệm hiện tại.

Hãy rà soát ứng dụng đã hoàn thành và dự thảo điều tra trước khi chuyển cho hội đồng.

KIỂM TRA VỀ KỸ THUẬT
1. Có kết nối mạng ra bên ngoài trong khi làm việc với hồ sơ hay không.
2. Có sử dụng CDN, phông chữ bên ngoài, dịch vụ speech-to-text đám mây, API bên ngoài hay không.
3. Tài liệu gốc, bản chép lời, mô hình cục bộ và bản sao lưu được lưu ở đâu.
4. Điều gì xảy ra khi xóa hồ sơ.
5. Tài liệu gốc có lọt vào nhật ký chẩn đoán hay không.
6. Nội dung hồ sơ có bị gửi ra ngoài khi xảy ra lỗi hay không.

KIỂM TRA VỀ PHƯƠNG PHÁP LUẬN
7. Mọi kết luận quan trọng có nguồn hay không.
8. Dữ kiện có được tách khỏi giả thuyết hay không.
9. Mọi yếu tố then chốt có được phản ánh trong phân tích nguyên nhân hay không.
10. Có gọi hành động của con người là nguyên nhân gốc rễ mà không phân tích các điều kiện hệ thống hay không.
11. Các biện pháp có gắn với nguyên nhân/rào chắn cụ thể hay không.
12. Mô hình có tự chỉ định người chịu trách nhiệm và thời hạn khi chưa có quyết định của hội đồng hay không.
13. Dự thảo báo cáo có bị trình bày như một văn bản đã được phê duyệt hay không.

KIỂM TRA VỀ BẢO MẬT
14. Những dữ liệu cá nhân/y tế nào đang nằm trong hồ sơ cục bộ.
15. Có cần che giấu dữ liệu bổ sung để trình diễn, công bố hoặc chuyển giao hay không.
16. Tên tệp và ảnh chụp màn hình có chứa họ tên không cần thiết hay không.

Trình bày kết quả dưới dạng bảng:
Hạng mục kiểm tra | Trạng thái | Rủi ro phát hiện được | Cần sửa gì | Ai phải xác nhận.

Không tự động sửa các kết luận nội dung của cuộc điều tra.

KIỂM TRA MỨC ĐỘ HOÀN THIỆN
17. Có bộ tình huống đối chứng và kết quả so sánh hay không.
18. Những chức năng nào đã ổn định, những chức năng nào vẫn còn mang tính thử nghiệm.
19. Những lỗi/hạn chế nào phải được khắc phục trước khi sử dụng trong sản xuất.
20. Giao diện có tạo ấn tượng sai rằng kết luận của AI là quyết định của hội đồng hay không.

Cách sử dụng các prompt

• Prompt 1 — quy trình đang vận hành hiện nay: chỉ dùng tài liệu đã được ẩn danh hóa từ trước; khóa khôi phục không được chuyển cho tác tử.
• Prompt 2–7 — các khối làm việc theo phương pháp luận, có thể dùng cả trong tác tử hiện tại lẫn trong môi trường cục bộ/máy chủ trong tương lai.
• Prompt 8 — xây dựng và tiếp tục hoàn thiện hệ thống thử nghiệm hoàn toàn ngoại tuyến.
• Prompt 9 — rà soát dự án thí điểm trước khi mở rộng phạm vi áp dụng.

Nguyên tắc cốt lõi của loạt bài vẫn giữ nguyên: trước hết bảo vệ dữ liệu và xác lập phương pháp luận, sau đó mới tự động hóa. AI tăng cường công việc của hội đồng, nhưng không thay thế tư duy chuyên môn, việc kiểm chứng dữ kiện và trách nhiệm của con người.