# AI trong hệ thống OT: được đề xuất, không được ra lệnh

> Ở nhà máy, đội vận hành không hỏi model của bạn thông minh đến đâu. Họ hỏi nó có ghi được vào PLC hay không, và câu trả lời phải nằm ngay trong bản thiết kế.

Bản gốc: https://fdetimes.net/vi/bach-khoa/an-toan-khi-ai-cham-vao-ot-iec-62443/

Sớm hay muộn, khi triển khai AI cho một nhà máy, một trạm bơm hay một tòa nhà, sẽ có người bên vận hành hỏi bạn: hệ thống này có ghi được gì vào PLC không? Cách bạn trả lời câu đó quyết định bạn được mời quay lại, hay dự án bị chuyển sang hàng chờ duyệt của phòng an ninh mạng.

Với phần mềm doanh nghiệp, một agent làm sai thì dữ liệu sai, ticket sai. Còn OT là các hệ thống điều khiển van, động cơ, lò nhiệt, nên sai lầm có thể đi thẳng ra thế giới vật lý.

Kỹ năng FDE cần ở đây vì thế không nằm ở prompt. Bạn phải thiết kế sao cho kể cả khi AI hỏng hoặc bị chiếm quyền, nó vẫn không gây hại được.

Tin tốt là bạn không phải tự nghĩ từ đầu. Cuối năm 2025, CISA, ASD ACSC và các đối tác quốc tế công bố hướng dẫn chung về tích hợp AI vào OT với bốn nguyên tắc: hiểu AI, cân nhắc kỹ việc dùng AI trong miền OT, xây khung quản trị và kiểm chứng (assurance), và nhúng thực hành an toàn, an ninh vào chính hệ thống.

Ghép bốn nguyên tắc này với ngôn ngữ của IEC 62443, bạn có ba quy tắc thiết kế dùng được ở bất kỳ khách hàng nào.

## Ba quy tắc: dữ liệu ra, người quyết, luôn có đường lùi

Quy tắc đầu tiên: dữ liệu được chảy ra, còn lệnh thì không được chảy vào. Hướng dẫn khuyến nghị dùng kiến trúc đẩy dữ liệu (push-based) hoặc truyền một chiều để giữ phân đoạn mạng OT và giảm đường tấn công, thay vì cho AI truy cập thường trực vào mạng điều khiển.

Mô hình mà hướng dẫn ưu tiên là đẩy dữ liệu OT đã làm sạch ra ngoài, sang một hệ thống AI tách biệt và được bảo vệ.

Quy tắc thứ hai: con người giữ quyết định. Theo hướng dẫn, các quyết định quan trọng có thể ảnh hưởng đến môi trường vật lý phải có người trong vòng lặp.

Các bản phân tích của giới luật cũng nhấn mạnh rằng sự giám sát của con người vẫn là yêu cầu then chốt với chức năng an toàn. Khi vẽ thành kiến trúc, cách làm dễ hiểu nhất là để AI chỉ đề xuất, còn vận hành viên duyệt và tự tay thao tác.

Quy tắc thứ ba: luôn có đường lùi. Hệ thống OT dùng AI phải có trạng thái lỗi được ghi thành tài liệu, và phải bỏ qua hoặc tắt được AI thật nhanh để vận hành viên quay về điều khiển thủ công hoặc điều khiển theo luật cố định.

Mục tiêu được nói rõ là fail-safe: một mô hình lỗi hay bị xâm nhập không thể tự đưa ra quyết định điều khiển nguy hiểm.

## IEC 62443 cho người mới: zone, conduit và mức an toàn

Để bàn ba quy tắc trên với đội an ninh OT của khách hàng, bạn cần nói cùng ngôn ngữ với họ, và ngôn ngữ đó thường là ISA/IEC 62443.

ISA mô tả bộ tiêu chuẩn này là tập yêu cầu và quy trình để triển khai, duy trì an ninh cho hệ thống tự động hóa và điều khiển công nghiệp (IACS) suốt vòng đời.

ISA coi trách nhiệm chia sẻ là một nguyên lý nền tảng của an ninh tự động hóa. Với một FDE, cách hiểu thực dụng là an ninh của phần hệ thống AI bạn mang vào cũng là việc của bạn, không chỉ của đội OT.

Hai khái niệm bạn sẽ dùng hằng ngày là zone và conduit. Các tài sản có nhu cầu bảo vệ giống nhau được gom vào một zone.

Giao tiếp giữa các zone phải đi qua conduit có kiểm soát, và mỗi zone, mỗi conduit có mức bảo vệ riêng tùy theo rủi ro. Tài liệu của Phoenix Contact định nghĩa conduit là một nhóm logic các tài sản mạng chỉ dùng để truyền thông giữa hai hay nhiều zone.

Khái niệm thứ ba hay bị hiểu sai là security level (SL). SL không phải một con số đơn lẻ mà là một vector trên bảy yêu cầu nền tảng (foundational requirements).

Ở hai đầu thang, SL1 nhắm tới việc sử dụng sai do vô ý, còn SL4 nhắm tới kẻ tấn công cấp quốc gia. Tiêu chuẩn còn chia SL thành ba loại, và mỗi loại gợi ra một câu hỏi khác nhau cho FDE:

| Loại | Ý nghĩa | Câu bạn nên hỏi |
|---|---|---|
| SL-T (mục tiêu) | Rút ra từ đánh giá rủi ro và mối đe dọa | Zone mà hệ thống AI nối vào có SL-T bao nhiêu, ai đã đánh giá? |
| SL-C (năng lực) | Khả năng của bản thân thiết bị, thành phần | Gateway và server mình mang vào đạt được tới mức nào? |
| SL-A (đạt được) | Kết quả của các biện pháp đã triển khai thực tế | Sau khi lắp đặt, cấu hình thật có đạt SL-T không? |

## Ví dụ: agent tối ưu điện năng cho một trạm bơm

Thử hình dung khách hàng là một công ty cấp nước, muốn có agent gợi ý lịch chạy bơm để giảm điện năng. Thiết kế ngây thơ là đặt agent trên một server trong mạng điều khiển, cho nó đọc và ghi trực tiếp vào PLC qua giao thức công nghiệp. Thiết kế đó chạy tốt trong demo nhưng vi phạm cả ba quy tắc cùng lúc.

Thiết kế đúng chia hệ thống thành ba phần. Zone điều khiển, gồm PLC và HMI, giữ nguyên. Một conduit một chiều đẩy dữ liệu historian đã lọc như lưu lượng, áp suất, công suất sang một zone AI tách biệt, và từ zone này không có đường nào quay về PLC.

Agent ghi đề xuất vào một hàng đợi. Vận hành viên xem đề xuất trên một màn hình riêng, đồng ý thì tự nhập thay đổi qua HMI.

Phía phần mềm, một đề xuất có thể trông như sau:

```python
from dataclasses import dataclass

@dataclass
class Recommendation:
    asset: str                 # ví dụ "bơm P-2"
    action: str                # ví dụ "giảm tần số biến tần"
    rationale: str             # dữ liệu nào dẫn tới đề xuất
    data_window: str           # khoảng thời gian dữ liệu đã dùng
    status: str = "proposed"   # proposed -> approved / rejected
    decided_by: str | None = None

def decide(rec: Recommendation, operator: str, approve: bool, audit_log: list) -> None:
    if rec.status != "proposed":
        raise ValueError("đề xuất này đã được xử lý")
    rec.status = "approved" if approve else "rejected"
    rec.decided_by = operator
    audit_log.append(rec)      # không có lệnh nào được gửi xuống thiết bị điều khiển
```

Điểm đáng chú ý nằm ở thứ hàm `decide` không làm: nó không gọi gì xuống OT. Người duyệt cũng thấy được lý do và khoảng dữ liệu đằng sau đề xuất, chứ không chỉ một nút OK.

Đi kèm code là một trang mô tả trạng thái lỗi: mất dữ liệu thì ngừng hiển thị đề xuất, cần tắt AI thì ai tắt, tắt ở đâu, và trạm quay về lịch chạy cố định nào.

## Bắt đầu thế nào khi đến khách hàng

Việc đầu tiên là ngồi với đội OT để vẽ sơ đồ zone và conduit hiện có, rồi hỏi SL-T của zone bạn định lấy dữ liệu. Sau đó đề xuất conduit một chiều, và liệt kê cụ thể những trường dữ liệu được đi ra. "Đã làm sạch" phải là một danh sách bạn ký tên được, không phải một tính từ.

Hướng dẫn chung coi rủi ro AI về bản chất là rủi ro dữ liệu, vì vậy danh sách đó quan trọng không kém chính model. Hướng dẫn cũng đề cập việc xác định vai trò của nhà cung cấp trong chuỗi cung ứng AI.

Phân tích của SecurityScorecard nhấn mạnh việc yêu cầu nhà cung cấp OT có nhúng AI minh bạch thành phần phần mềm, chẳng hạn bằng SBOM. Nếu bạn là nhà cung cấp, hãy chuẩn bị SBOM trước khi khách hỏi.

Nếu khách hàng làm về tòa nhà hoặc kiểm soát ra vào, hãy đọc thêm NIST SP 800-82 Rev. 3 (tháng 9/2023). Bản này mở rộng phạm vi từ ICS sang OT nói chung, gồm cả tự động hóa tòa nhà và kiểm soát truy cập vật lý.

## Những sai lầm khiến thiết kế bị trả về

Sai lầm phổ biến nhất là hiểu "read-only" chỉ ở mức quyền. Một tài khoản chỉ có quyền đọc nhưng chạy trên một kết nối hai chiều thường trực vẫn là một đường vào mạng điều khiển, đúng thứ mà kiến trúc đẩy một chiều sinh ra để loại bỏ.

Sai lầm thứ hai là biến người duyệt thành một nút bấm theo thói quen: nếu vận hành viên không thấy lý do đằng sau đề xuất, họ đang ký chứ không phải duyệt.

Sai lầm thứ ba là có công tắc tắt nhưng không có tài liệu và chưa ai diễn tập. Thứ tư là nói "hệ thống đạt SL2" như thể SL là một con số, trong khi đội OT sẽ hỏi lại từng yêu cầu nền tảng và bạn đang nói về SL-T, SL-C hay SL-A.

Về sự nghiệp, khi gặp IEC 62443, NIST SP 800-82 hay OT/ICS trong một mô tả công việc, hãy chuẩn bị sẵn một thiết kế như ví dụ trạm bơm để trình bày trong phỏng vấn, kèm sơ đồ zone và conduit.

Trên CV, hãy mô tả cụ thể việc bạn đã làm thay vì chỉ liệt kê tên tiêu chuẩn, chẳng hạn: "Thiết kế luồng dữ liệu một chiều từ historian sang zone AI tách biệt theo mô hình zone/conduit, kèm quy trình duyệt của vận hành viên và tài liệu trạng thái lỗi."

Với đội vận hành, một FDE đáng tin là người tự nói ra trước AI của mình không làm được những gì, rồi chỉ cho họ thấy điều đó nằm ở đâu trong sơ đồ.

**Thử ngay tuần này:**

- Vẽ sơ đồ zone và conduit cho một hệ thống bạn đang làm (hoặc một trạm bơm giả định), rồi đánh dấu mọi đường có thể đi ngược từ AI về thiết bị điều khiển.
- Viết một trang mô tả trạng thái lỗi: AI hỏng thì hệ thống làm gì, ai tắt AI, tắt ở đâu và quay về chế độ vận hành nào.
- Đọc mục lục NIST SP 800-82 Rev. 3 và trang giới thiệu ISA/IEC 62443, ghi lại năm thuật ngữ bạn sẽ dùng trong buổi họp đầu với đội OT.

## Nguồn

- [Joint guidance on principles for the secure integration of artificial intelligence in operational technology](https://cyber.gc.ca/en/news-events/joint-guidance-principles-secure-integration-artificial-intelligence-operational-technology)

- [NSA, CISA Guidance Demands a Secure-by-Design Approach for AI in OT](https://www.secureworld.io/industry-news/guidance-secure-ai-ot)

- [CISA and Partners Publish “Secure Integration of AI in OT” Framework](https://www.pillsburylaw.com/en/news-and-insights/cisa-ai-ot-framework.html)

- [CISA's New AI Guidance: The Leadership Imperative for OT Supply Chain Security](https://securityscorecard.com/blog/cisas-new-ai-guidance-the-leadership-imperative-for-ot-supply-chain-security/)

- [ISA/IEC 62443 Series of Standards](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)

- [What is IEC 62443? (itemis glossary)](https://www.itemis.com/en/glossary/iec-62443/)

- [Zones and Conduits (with Protection Needs Analysis)](https://engineer.plcnext.help/latest/ZonesConduits.htm)

- [Security levels](https://security.plcnext.help/se/Industrial_Security_Guideline/Concepts_and_tools/SecurityLevels.htm)

- [NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)