Physical AI vào EU: Robot thông minh giờ phải chứng minh mình an toàn

Physical AI bước vào giai đoạn mới: từ màn trình diễn robot đến điều kiện được bán hàng

Tôi thấy nhiều đội làm robot vẫn đang kể câu chuyện theo kiểu cũ: camera tốt hơn, model nhận diện chính xác hơn, cánh tay gắp nhanh hơn, xe tự hành biết né vật cản. Những thứ đó quan trọng, nhưng chưa đủ để bán hàng ở châu Âu. Với Physical AI, câu hỏi không còn dừng ở việc hệ thống có thông minh hay không. Câu hỏi thực tế hơn là: khi nó nhận diện sai, bị tấn công, cập nhật phần mềm lỗi hoặc gặp tình huống chưa từng thấy, nó sẽ làm gì với con người, máy móc và tài sản ở xung quanh?

Bài phân tích của Reuters ngày 10/08/2026 chỉ ra một chuyển động đáng chú ý từ EU: thay vì dựng một đạo luật riêng mang nhãn “Physical AI”, EU đang nối AI Act vào hệ thống luật an toàn sản phẩm sẵn có. Digital Omnibus on AI, theo Regulation (EU) 2026/1744, có hiệu lực từ 27/07/2026. Ý nghĩa của nó không nằm ở một tên gọi mới. Ý nghĩa nằm ở đường vào thị trường: robot, máy tự hành, thiết bị công nghiệp có AI và các sản phẩm cyber-physical phải được xem như sản phẩm an toàn có phần mềm phức tạp, thay vì một ứng dụng AI được đóng gói đẹp mắt.

Khác biệt này nghe có vẻ pháp lý, nhưng nó tác động thẳng vào kiến trúc sản phẩm. Một chatbot trả lời dở có thể làm người dùng khó chịu. Một robot kho vận nhận diện sai lối đi có thể va vào người hoặc hàng hóa. Một hệ thống tránh va chạm hiểu sai cảm biến có thể đưa ra quyết định nguy hiểm. Một thiết bị y tế dùng AI đánh giá sai dữ liệu có thể tạo ra hậu quả nghiêm trọng hơn rất nhiều so với việc một LLM bịa ra câu trả lời.

Tôi nghiêng về nhận định này: cuộc chơi Physical AI trong vài năm tới sẽ không thuộc về công ty có bản demo ấn tượng nhất. Nó sẽ nghiêng về công ty chứng minh được hệ thống của mình có giới hạn rõ ràng, có cơ chế dừng, có nhật ký để điều tra, có bản vá được kiểm soát và có người chịu trách nhiệm khi sự cố xảy ra. Đó là lý do tôi gọi đây là giai đoạn compliance-by-design, không phải một màn kiểm tra giấy tờ ở cuối dự án.

Vì sao robot thông minh không còn chỉ là một sản phẩm công nghệ

Physical AI là nhóm sản phẩm dùng AI để nhận biết, diễn giải, ra quyết định hoặc hành động trong thế giới vật lý. Phạm vi này có thể gồm robot, xe tự hành trong kho, thiết bị công nghiệp có AI, hệ thống tránh va chạm, chức năng dừng khẩn cấp, thiết bị y tế hoặc hệ thống xử lý dữ liệu sinh trắc học.

Điểm chung của chúng là một chuỗi nhân quả rất ngắn: dữ liệu đầu vào, quyết định của model, tín hiệu điều khiển, hành động vật lý và hậu quả. Nếu lỗi xuất hiện ở bất kỳ mắt xích nào, hậu quả không nằm trong cửa sổ chat. Nó hiện diện ở bánh xe, cánh tay máy, bộ truyền động, cửa tự động hoặc quyết định tác động lên con người.

Vì vậy, với Physical AI, “độ chính xác trung bình” là một thước đo dễ gây ngộ nhận. Điều cần biết là hệ thống sai ở đâu, sai trong điều kiện nào, có nhận ra mình không chắc chắn hay không, và khi không chắc chắn thì có chuyển về trạng thái an toàn hay không. Đội kỹ thuật nào chỉ mang benchmark model đi gặp khách hàng sẽ sớm gặp một câu hỏi khó hơn: “Nếu model sai thì máy làm gì?”

Nghịch lý của năm 2026: AI phần mềm được tiêu dùng hóa, AI vật lý bị sản phẩm hóa

Năm 2026 cho thấy hai tốc độ phát triển hoàn toàn khác nhau. Theo các thông tin được The Verge đề cập, OpenAI được báo cáo đã chuyển từ cơ cấu doanh thu 60% consumer/40% enterprise đầu năm sang trạng thái doanh thu enterprise vượt doanh thu người dùng cá nhân. Google đưa Gemini 3.7 Flash vào AI Mode của Search. Google Meet bổ sung ghi âm, phiên âm, biên bản và action items cho các cuộc họp trực tiếp. Grok được quảng bá như một “AI teammate”. Cursor hoàn tất thương vụ SpaceX trị giá 60 tỷ USD.

Ở lớp phần mềm, AI đang được đóng gói thành tính năng hàng ngày: hỏi đáp, ghi chú, tìm kiếm, viết code, giao việc. Người dùng thử một tính năng, thấy không hợp thì tắt. Cùng tư duy đó mà mang sang robot sẽ rất nguy hiểm. Bạn không thể “thử nghiệm với người dùng” theo kiểu sản phẩm SaaS khi robot có thể đi lại giữa công nhân, xe nâng và hàng hóa.

Đây cũng là điểm cần phân biệt với làn sóng Agentic AI và tự động hóa. AI Agent trong phần mềm cần quyền hạn có kiểm soát, log và cơ chế phê duyệt. Physical AI cần toàn bộ các lớp đó, cộng thêm an toàn chức năng, giới hạn vận hành và khả năng đưa thiết bị về trạng thái an toàn. Một Agent gửi nhầm email đã phiền; một Agent điều khiển robot đi nhầm hướng là vấn đề khác hẳn.

Digital Omnibus on AI của EU đã thay đổi đường vào thị trường như thế nào?

Digital Omnibus on AI không tạo ra một “giấy phép Physical AI” chung cho mọi sản phẩm. EU chọn cách khó hơn nhưng thực tế hơn: quản lý theo ngành và theo loại rủi ro. Robot công nghiệp và AI nhúng trong máy móc sẽ chủ yếu đi qua Machinery Regulation, rồi được bổ sung bằng các đạo luật ủy quyền liên quan đến an toàn AI. Song song, sản phẩm có yếu tố số phải đối mặt với Cyber Resilience Act, trách nhiệm sản phẩm, bảo vệ dữ liệu và các yêu cầu liên quan khác.

Cách làm này buộc doanh nghiệp bỏ một thói quen phổ biến: giao toàn bộ phần “AI compliance” cho pháp chế hoặc một nhóm trust and safety đứng tách khỏi nhóm sản phẩm. Với robot, compliance nằm rải ngay trong thiết kế cơ khí, firmware, model, cloud service, quy trình cập nhật và hậu mãi.

EU không lập luật riêng cho Physical AI

Nghe qua, việc không có luật riêng có thể khiến doanh nghiệp nghĩ rằng Physical AI chưa bị siết. Tôi nghĩ ngược lại. Một luật riêng đôi khi tạo ra một checklist rõ ràng để tích vào. Mô hình theo ngành khiến doanh nghiệp phải chứng minh sự nhất quán giữa nhiều lớp yêu cầu: máy có an toàn không, AI có tạo rủi ro không, phần mềm có bị xâm nhập không, dữ liệu có hợp pháp không, nhà sản xuất có theo dõi sự cố sau khi bán không.

Điều này phản ánh đúng bản chất của sản phẩm. Robot không tự nhiên biến thành “AI product” chỉ vì đội marketing gắn thêm LLM hoặc computer vision. Nó vẫn là một cỗ máy có chuyển động, có năng lượng, có cảm biến và có khả năng gây hại. AI chỉ làm số lượng trạng thái và tình huống cần kiểm soát tăng lên.

Từ AI Act sang Machinery Regulation

Với robot công nghiệp và AI nhúng trong máy móc, Machinery Regulation là trục chính. AI Act không biến mất, nhưng yêu cầu AI rủi ro cao liên quan đến sản phẩm an toàn sẽ được tích hợp theo hướng phù hợp với khung luật máy móc. Điều quan trọng ở đây là đội sản phẩm phải ngừng chia sản phẩm thành hai phần tưởng tượng: “phần máy” cho kỹ sư cơ khí và “phần AI” cho data team.

Một ví dụ dễ hiểu: nếu AI quyết định khi nào robot giảm tốc, đổi hướng hoặc dừng khẩn cấp, thì model đó liên quan trực tiếp đến chức năng an toàn. Nó không còn là một tính năng phụ để thay model tùy ý. Mỗi thay đổi về dữ liệu, threshold, logic fallback hoặc pipeline inference đều cần được nhìn từ góc độ tác động đến hành vi vật lý.

Khi nào sản phẩm phải chịu cả AI Act và luật sản phẩm?

Không phải mọi sản phẩm đi theo cùng một đường. Reuters lưu ý rằng các nhóm như đồ chơi, thang máy và sản phẩm thuộc Annex I của AI Act vẫn có thể chịu cả luật sản phẩm liên quan lẫn AI Act. Vì vậy, doanh nghiệp không nên hỏi chung chung “robot của tôi có thuộc AI Act không?”. Câu hỏi hữu ích hơn là: AI đang làm chức năng gì, sản phẩm thuộc nhóm nào, AI có phải thành phần an toàn không, có kết nối mạng không, có xử lý dữ liệu sinh trắc học không, và ai là bên đưa sản phẩm ra thị trường EU?

Đây là công việc lập bản đồ phạm vi. Nó nghe chán hơn xây model, nhưng làm sai ở đây thì cả roadmap chứng nhận phía sau có thể sai.

Lộ trình tuân thủ 2026-2028: doanh nghiệp không thể chờ đến ngày luật bắt đầu

Điểm dễ gây chủ quan nhất là các mốc nghĩa vụ rủi ro cao còn nằm ở 2027 và 2028. Nhiều startup sẽ đọc đến đó rồi kết luận: “Còn thời gian.” Nhưng hồ sơ kỹ thuật, thử nghiệm, kiến trúc cập nhật an toàn và quy trình hậu mãi không thể mọc lên trong vài tháng trước ngày bán hàng.

Trước ngày 02/12/2026: minh bạch nội dung và các lệnh cấm mới

Các biện pháp minh bạch nội dung, gồm watermarking, phải được triển khai trước 02/12/2026. Reuters cũng đề cập các lệnh cấm liên quan đến hệ thống tạo hoặc thao túng nội dung thân mật không có sự đồng thuận và tài liệu lạm dụng tình dục trẻ em.

Với một nhà sản xuất robot, watermarking có thể chưa phải ưu tiên số một. Nhưng đừng bỏ qua ý nghĩa rộng hơn: EU đang yêu cầu nhà cung cấp có khả năng nhận diện, kiểm soát và giải trình cách AI tạo ra hoặc xử lý nội dung. Nếu robot có camera, giao diện giọng nói hoặc tạo dữ liệu hình ảnh phục vụ vận hành, đội sản phẩm cần biết dữ liệu nào đi đâu, ai có quyền truy cập và nó có thể bị tái sử dụng như thế nào.

Ngày 11/09/2026: Cyber Resilience Act bắt đầu tạo áp lực vận hành

Từ 11/09/2026, Cyber Resilience Act bắt đầu yêu cầu báo cáo sự cố và lỗ hổng. Các mốc rất cụ thể: cảnh báo sớm trong 24 giờ, báo cáo trong 72 giờ và báo cáo cuối trong 14 ngày. Toàn bộ CRA áp dụng từ 11/12/2027.

Những mốc này khiến cybersecurity không thể là việc “gọi vendor vào xử lý” khi có chuyện. Nhà sản xuất cần biết ai phát hiện sự cố, ai có quyền đánh giá mức độ, ai gửi cảnh báo, ai giữ bằng chứng kỹ thuật, ai thông báo khách hàng và ai phát hành bản vá. Nếu robot của bạn phụ thuộc vào cloud, mobile app, gateway hoặc API quản trị từ xa, phạm vi kiểm soát còn rộng hơn nhiều so với bản thân thiết bị.

Năm 2027 và 2028: hai nhóm AI rủi ro cao

AI rủi ro cao độc lập bắt đầu chịu nghĩa vụ từ 02/12/2027. AI rủi ro cao nhúng trong sản phẩm an toàn bắt đầu từ 02/08/2028. Sự phân biệt này rất quan trọng. Một hệ thống AI độc lập và một AI điều khiển chức năng có liên quan tới an toàn không thể được quản trị giống nhau.

Tôi sẽ không chờ đến 2028 mới hành động nếu đang làm robot xuất khẩu. Chu kỳ phát triển phần cứng, kiểm thử, tích hợp, hợp đồng phân phối và chứng nhận vốn đã dài. Nếu tới sát mốc mới bắt đầu hỏi về log, đánh giá rủi ro hoặc chính sách cập nhật, doanh nghiệp sẽ phải sửa kiến trúc trong thế bị động.

Hồ sơ kỹ thuật mới là lợi thế cạnh tranh: compliance-by-design thay cho chữa cháy pháp lý

Điểm tôi đánh giá cao trong hướng tiếp cận mới là nó ép doanh nghiệp xây một hồ sơ kỹ thuật thống nhất. Nhiều công ty hiện có tài liệu rời rạc: nhóm AI giữ dataset và benchmark, nhóm embedded giữ firmware, nhóm security giữ danh sách lỗ hổng, bộ phận chất lượng giữ báo cáo test, còn pháp chế giữ hợp đồng. Khi xảy ra sự cố, chẳng ai ráp được một câu chuyện hoàn chỉnh về lý do hệ thống đã hành động như vậy.

Với Physical AI, hồ sơ tốt phải trả lời được chuỗi câu hỏi từ đầu đến cuối: sản phẩm được thiết kế để làm gì, giới hạn vận hành là gì, model dùng dữ liệu nào, model được test ra sao, khi confidence thấp thì hệ thống phản ứng thế nào, quyền điều khiển được phân tách thế nào, bản cập nhật được xác thực ra sao, log có đủ để điều tra không và khi phát hiện lỗi thì quy trình thu hồi hoặc sửa chữa vận hành thế nào.

Một hệ thống quản trị cho nhiều đạo luật

Tôi không khuyên lập một bộ hồ sơ riêng cho AI Act, một bộ khác cho Machinery Regulation và bộ thứ ba cho CRA. Cách đó tạo ra ba phiên bản sự thật, rồi tới lúc audit sẽ tự mâu thuẫn. Hãy có một nền tảng bằng chứng dùng chung, trong đó liên kết được thiết kế an toàn, dữ liệu huấn luyện, đánh giá rủi ro, kiểm thử model, an ninh mạng, nhật ký sự kiện, cập nhật phần mềm và trách nhiệm sản phẩm.

Điểm then chốt là traceability. Một yêu cầu an toàn phải truy được tới thiết kế. Một thay đổi model phải truy được tới dữ liệu, phiên bản phần mềm, kết quả kiểm thử và đánh giá ảnh hưởng. Một sự cố ngoài hiện trường phải truy ngược được về phiên bản đang chạy trên thiết bị. Nếu không làm được việc đó, nói về “AI governance” chỉ là nói cho hay.

Đăng ký ngay cả khi cho rằng sản phẩm nằm ngoài phạm vi

Một thay đổi Reuters nhấn mạnh là nhà cung cấp phải đăng ký hệ thống AI vào cơ sở dữ liệu EU đối với AI rủi ro cao, kể cả khi họ cho rằng hệ thống nằm ngoài phạm vi. Đây là quy định dễ gây khó chịu cho doanh nghiệp, vì nó đòi hỏi công khai lập luận phân loại thay vì chỉ tự giữ trong nội bộ.

Nhưng về mặt vận hành, đây lại là tín hiệu rõ ràng: phân loại sản phẩm phải là một quy trình có bằng chứng. Không thể chỉ có một dòng trong slide gọi sản phẩm là “low risk”. Doanh nghiệp cần ghi rõ use case, người dùng dự kiến, môi trường vận hành, các chức năng an toàn liên quan và lý do kết luận về phạm vi pháp lý.

Giám sát sau bán hàng không còn là chức năng phụ

Robot sau khi giao cho khách không phải là dự án đã đóng. Model có thể gặp dữ liệu khác dự kiến. Cảm biến có thể xuống cấp. Khách hàng có thể thay đổi bố trí kho. Kẻ tấn công có thể phát hiện lỗ hổng mới. Một bản cập nhật nhỏ có thể thay đổi thời gian phản hồi của hệ thống.

Do đó, post-market monitoring phải nằm trong sản phẩm từ đầu. Thiết bị cần log phù hợp. Nhà sản xuất cần kênh nhận báo cáo. Đội kỹ thuật cần có quy trình phân tích hành vi ngoài dự kiến. Bộ phận hậu mãi cần biết khi nào chỉ cần vá phần mềm, khi nào cần ngừng vận hành, và khi nào phải thông báo rộng hơn. Một robot không được quan sát sau khi bán là một sản phẩm mà nhà sản xuất đã tự bịt mắt mình.

An ninh mạng trở thành một phần của an toàn vật lý

Một robot có cơ chế dừng khẩn cấp tốt nhưng dễ bị chiếm quyền điều khiển từ xa vẫn không phải robot an toàn. Đây là sai lầm tư duy phổ biến: coi safety và security là hai checklist độc lập. Trong Physical AI, security failure có thể biến trực tiếp thành safety failure.

Từ lỗi model đến chuyển động nguy hiểm

Chuỗi rủi ro có thể bắt đầu từ dữ liệu cảm biến sai, model nhận diện sai, logic quyết định sai hoặc lệnh điều khiển bị can thiệp. Sau đó là hành động vật lý. Đó có thể là chuyển động ngoài ý muốn, tương tác không an toàn hoặc quyết định nguy hiểm.

Vấn đề không nằm ở việc có thể liệt kê các rủi ro này. Vấn đề là kiến trúc sản phẩm có chặn được chuỗi đó hay không. Hệ thống nên có các lớp kiểm soát độc lập với model khi mức rủi ro đủ cao. Nếu mọi quyết định đều phụ thuộc vào một model hoặc một dịch vụ cloud, bạn đã tạo ra một single point of failure rất đáng sợ.

CRA và AI Act cần được xây dựng trên cùng một lớp kiến trúc

Về kỹ thuật, doanh nghiệp cần thiết kế các lớp như secure boot, quản lý danh tính thiết bị, phân vùng quyền điều khiển, cập nhật an toàn, quản lý lỗ hổng và cơ chế dừng khẩn cấp. Tôi không nói đây là một danh sách để “đạt chuẩn” bằng cách tick box. Mỗi lớp phải gắn với một kịch bản thất bại cụ thể.

Ví dụ, cập nhật từ xa không chỉ cần chữ ký số. Nó còn cần cơ chế rollback an toàn, kiểm thử trước triển khai và giới hạn việc một bản cập nhật có thể thay đổi hành vi nào. Với hệ thống vật lý, cập nhật phần mềm là thay đổi hành vi của máy. Đừng đối xử với nó như đổi màu giao diện web.

Vì sao bản vá phần mềm không đủ?

Một bản vá có thể xử lý lỗ hổng bảo mật nhưng tạo ảnh hưởng mới lên hiệu năng hoặc tính dự đoán của hệ thống. Model mới có thể nhận diện tốt hơn trong dữ liệu test nhưng phản hồi chậm hơn trên phần cứng thực. Một thư viện được nâng cấp có thể thay đổi hành vi inference. Vì vậy, sau cập nhật, doanh nghiệp phải đánh giá lại ảnh hưởng tới an toàn chức năng và hồ sơ kỹ thuật liên quan.

Bài học này cũng liên quan đến tư duy điều phối AI Agent. Như tôi từng viết trong bài về Multi-Agent orchestration, quyền hạn phải được giới hạn theo đúng nhiệm vụ. Khi Agent hoặc model chạm đến thiết bị vật lý, giới hạn đó cần cứng hơn: quyền đọc khác quyền đề xuất, quyền đề xuất khác quyền ra lệnh, và quyền ra lệnh khác quyền vượt qua cơ chế an toàn.

Dữ liệu nhạy cảm, thiên lệch và quyền riêng tư trong robot có thị giác

Robot có camera trong kho, bệnh viện, cửa hàng hoặc nhà máy tạo ra một bài toán dữ liệu không hề nhỏ. Hệ thống có thể nhìn thấy khuôn mặt, hành vi người lao động, đặc điểm sinh trắc học, môi trường làm việc và các tình huống không liên quan trực tiếp đến nhiệm vụ của máy.

Tiêu chuẩn “strict necessity” thay đổi cách huấn luyện mô hình

Digital Omnibus on AI khôi phục tiêu chuẩn strict necessity đối với việc xử lý dữ liệu cá nhân nhạy cảm để phát hiện và sửa thiên lệch. Nói đơn giản: doanh nghiệp chỉ được xử lý dữ liệu nhạy cảm khi dữ liệu đó thực sự không thể thiếu cho mục tiêu quản trị model.

Đây là cú đánh vào cách nói rất tiện miệng của nhiều công ty: “Chúng tôi thu thập để cải thiện AI.” Cải thiện AI không phải một mục đích đủ cụ thể. Cần trả lời cải thiện phần nào, thiên lệch nào đang được kiểm tra, tại sao không dùng dữ liệu ít nhạy cảm hơn, ai được truy cập, lưu trong bao lâu và bằng chứng nào chứng minh việc xử lý là cần thiết.

Thiên lệch trong robot gây hậu quả khác thiên lệch trong chatbot

Chatbot trả lời sai có thể gây hiểu lầm. Robot phân loại sai con người, xe tự hành nhận diện sai chướng ngại vật hoặc thiết bị y tế đánh giá sai bệnh nhân có thể dẫn tới một hành động sai trong thế giới thật. Hệ quả vật lý khiến việc đánh giá thiên lệch không thể chỉ là kiểm tra một vài chỉ số fairness trong báo cáo.

Nhà sản xuất cần xem bias như một dạng rủi ro hệ thống: dữ liệu có đại diện cho môi trường vận hành không, điều kiện ánh sáng có gây sai lệch không, cảm biến có hoạt động khác nhau với các đối tượng khác nhau không, và khi không chắc chắn thì hệ thống có giảm mức tự chủ hay chuyển sang kiểm soát của con người không.

Doanh nghiệp Việt Nam cần chuẩn bị gì nếu muốn xuất khẩu robot và máy móc có AI sang EU?

Với doanh nghiệp Việt Nam, sai lầm lớn nhất là xem EU compliance là chi phí xuất khẩu phát sinh sau khi đã làm xong sản phẩm. Nếu khách hàng EU yêu cầu bằng chứng an toàn, quản lý lỗ hổng và khả năng báo cáo sự cố mà bạn mới bắt đầu gom tài liệu, khả năng cao bạn đang đứng ngoài vòng đánh giá nhà cung cấp.

Bước 1: lập bản đồ sản phẩm và phạm vi pháp lý

Hãy bắt đầu bằng một tài liệu ngắn nhưng thật: AI độc lập hay AI nhúng, có phải thành phần an toàn không, đây là máy móc hay một loại sản phẩm khác, có yếu tố số kết nối mạng không, có xử lý dữ liệu sinh trắc học không, ai là nhà sản xuất, ai là nhà tích hợp và ai là bên đưa sản phẩm ra thị trường EU.

Đừng để sales tự trả lời các câu hỏi này. Cần có kỹ sư sản phẩm, kỹ sư an toàn, security và pháp chế cùng xác nhận. Một mô tả use case mơ hồ sẽ kéo theo phân loại mơ hồ.

Bước 2: xây dựng nhóm liên chức năng

Startup robot thường mạnh ở một vài mảng: cơ khí, computer vision hoặc điều hướng. Nhưng để bán vào EU, bạn cần kết nối kỹ sư AI, kỹ sư an toàn chức năng, chuyên gia an ninh mạng, pháp chế, quản lý chất lượng và bộ phận hậu mãi. Không nhất thiết mọi vai trò đều tuyển full-time ngay từ đầu. Nhưng trách nhiệm phải được chỉ định, không thể để khoảng trống.

Tôi cho rằng founder nên trực tiếp tham gia ít nhất giai đoạn đầu của việc này. Không phải vì founder cần hiểu từng điều luật, mà vì mọi yêu cầu tuân thủ đều có thể biến thành quyết định sản phẩm: thêm cảm biến hay không, giữ dữ liệu tại thiết bị hay trên cloud, có cho cập nhật từ xa hay không, ai có quyền override máy, và chi phí bảo hành sẽ chịu thế nào.

Bước 3: chuẩn hóa bộ bằng chứng

Bộ bằng chứng cần gồm tài liệu thiết kế, kết quả kiểm thử, đánh giá rủi ro, kiểm soát dữ liệu, quản lý lỗ hổng, nhật ký vận hành và quy trình thu hồi hoặc khắc phục. Mỗi artifact không cần đẹp như brochure. Nó cần nhất quán, có phiên bản và truy được nguồn gốc.

Đây cũng là lúc doanh nghiệp nên đầu tư vào quản trị version cho model, dataset và firmware. Nếu không thể trả lời chính xác thiết bị của khách hàng đang chạy phiên bản nào, dùng model nào và được cập nhật vào thời điểm nào, bạn gần như không có nền tảng để vận hành sau bán hàng.

Bước 4: thiết kế theo mốc 2026-2028

Roadmap nên bám các mốc thực thi: yêu cầu minh bạch trước 02/12/2026; nghĩa vụ CRA về báo cáo sự cố và lỗ hổng từ 11/09/2026; toàn bộ CRA từ 11/12/2027; AI rủi ro cao độc lập từ 02/12/2027; AI rủi ro cao nhúng trong sản phẩm an toàn từ 02/08/2028.

Đây không phải lịch để đợi. Đây là lịch để lùi ngược từ ngày sản phẩm cần bán. Nếu dự án xuất khẩu cần chứng nhận, thử nghiệm thực địa và tích hợp với khách hàng, hãy dành thời gian cho việc chứng minh sản phẩm chứ đừng chỉ dành thời gian cho việc xây nó.

Physical AI sẽ không thắng nhờ lời hứa “robot của chúng tôi dùng AI”. Nó thắng khi nhà sản xuất chứng minh được AI có thể bị giới hạn, bị kiểm tra và bị chịu trách nhiệm.

Câu hỏi thường gặp

Physical AI có phải là một đạo luật riêng của EU không?

Không. EU đang quản lý theo ngành và theo loại sản phẩm. Robot công nghiệp và AI nhúng trong máy móc chịu tác động chính từ Machinery Regulation, rồi kết hợp với các yêu cầu mục tiêu từ AI Act, Cyber Resilience Act và các luật an toàn sản phẩm liên quan.

Robot công nghiệp có phải tuân thủ AI Act đầy đủ ngay trong năm 2026 không?

Các nghĩa vụ có mốc trong năm 2026 đã tạo áp lực chuẩn bị, gồm yêu cầu minh bạch nội dung trước 02/12/2026. Chế độ AI rủi ro cao đối với AI nhúng làm thành phần an toàn có mốc bắt đầu 02/08/2028. Dù vậy, thiết kế, tài liệu và quy trình vận hành cần được chuẩn bị trước nhiều so với ngày đó.

Cyber Resilience Act quan trọng gì với robot?

CRA xử lý lớp an ninh mạng của sản phẩm có yếu tố số. Với robot, lỗ hổng bảo mật có thể dẫn tới rủi ro an toàn vật lý. Nghĩa vụ báo cáo sự cố và lỗ hổng bắt đầu từ 11/09/2026, với các mốc 24 giờ, 72 giờ và 14 ngày; toàn bộ CRA áp dụng từ 11/12/2027.

Doanh nghiệp có được dùng dữ liệu nhạy cảm để sửa thiên lệch AI không?

Có thể, nhưng phải theo tiêu chuẩn strict necessity. Doanh nghiệp cần chứng minh dữ liệu nhạy cảm thực sự không thể thiếu để phát hiện và sửa thiên lệch, thay vì viện lý do chung chung là cải thiện model.

Thông điệp chiến lược quan trọng nhất cho startup Physical AI là gì?

Đừng coi compliance là thủ tục cuối trước khi xuất hàng. Với robot và máy móc có AI, an toàn, cybersecurity, quản trị dữ liệu, log, cập nhật và giám sát sau bán hàng phải được thiết kế cùng sản phẩm. Làm sau thường đắt hơn, chậm hơn và khó sửa hơn.

Nguồn tham khảo: Physical AI 2026: Vì sao robot thông minh phải vượt qua “bài kiểm tra tuân thủ” trước khi vào thị trường EU?