# Tích hợp công nghệ sự kiện và quy trình hỗ trợ

- Published: 2026-11-12T10:18:30+07:00
- Updated: 2026-11-12T12:08:22+07:00
- Author: Cuong Ta Quoc
- Categories: G Blog
- Canonical: https://gct-solutions.net/blogs/event-technology-integration-support-workflow
- Language: vi

> Cách kết nối hệ thống sự kiện, kênh liên lạc và quy trình hỗ trợ mà không làm mất danh tính, ngữ cảnh, quyền sở hữu hay bằng chứng vận hành.

Cách kết nối hệ thống sự kiện, kênh liên lạc và quy trình hỗ trợ mà không làm mất danh tính, ngữ cảnh, quyền sở hữu hay bằng chứng vận hành.

Tích hợp công nghệ sự kiện (event technology integration) có thể kết nối đăng ký, ứng dụng di động, CRM, email, nhắn tin, bán vé, analytics và công cụ tại chỗ. Kết nối các hệ thống này không chỉ là đồng bộ dữ liệu. Hai hệ thống có thể trao đổi bản ghi hoàn hảo mà đội hỗ trợ vẫn không trả lời được câu hỏi đơn giản nhất trong ngày diễn ra: ngay lúc này, ai đang sở hữu vấn đề này?

Đó là lý do tích hợp event tech stack nên được coi là một mô hình vận hành cũng như một dự án kỹ thuật. Tích hợp phải giữ được danh tính, ngữ cảnh, quyền sở hữu và kết quả cuối cùng của một yêu cầu. Bài viết này, từ GCT Solutions, trình bày cách thiết kế cho điều đó, từ lập bản đồ vòng đời đến diễn tập sự cố, và kết thúc bằng một bản rà soát mức sẵn sàng mà bạn có thể dùng trước sự kiện tiếp theo.

## Vì sao tích hợp công nghệ sự kiện là câu hỏi về mô hình vận hành, không chỉ là bài toán đồng bộ dữ liệu

Hầu hết kế hoạch tích hợp bắt đầu bằng câu hỏi trường dữ liệu nào nên chuyển giữa hệ thống nào. Câu hỏi đó quan trọng, nhưng chưa đủ. Cvent, khi bàn về việc kết nối marketing và công nghệ sự kiện, ghi nhận rằng đồng bộ dữ liệu phát sinh từ sự kiện vào CRM [giúp sales và marketing làm việc trên cùng một dữ liệu](https://www.cvent.com/en/blog/events/martech-event-tech). Lợi ích là có thật, và nó đến từ sự đồng thuận về dữ liệu nào của ai, không chỉ từ bản thân kết nối.

Công việc hỗ trợ làm lộ khoảng trống này. Một yêu cầu hỗ trợ chạm vào nhiều hệ thống cùng lúc: bản ghi đăng ký, chương trình, kênh liên lạc, có thể cả thanh toán hay vé. Nếu các hệ thống được tích hợp ở cấp khách tham dự nhưng không có gì kết nối chính yêu cầu hỗ trợ, thì quyền sở hữu và khả năng phục hồi chỉ còn là phỏng đoán. Các phần dưới đây xây dựng từng mảnh để lấp khoảng trống đó.

## Lập bản đồ event tech stack trước, trong và sau sự kiện

![Các hệ thống công nghệ sự kiện được kết nối xuyên suốt ba giai đoạn trước, trong và sau sự kiện.](https://gct-solutions.net/media/serve/218/gct-solutions-mapping-the-event-tech-stack-across-before-during-and-after-the-event.webp)

Hãy bắt đầu bằng việc lập bản đồ hệ thống và quy trình qua ba giai đoạn của sự kiện, vì nhu cầu hỗ trợ, và do đó nhu cầu tích hợp, khác nhau ở mỗi giai đoạn.

### Trước sự kiện: đăng ký, thanh toán và truy cập tài khoản

Các nhu cầu phổ biến gồm trạng thái đăng ký, thanh toán, thông tin đi lại, câu hỏi về chương trình, yêu cầu tiếp cận và truy cập tài khoản. Phần lớn có thể dự đoán, và nhiều việc có thể trả lời từ thông tin đã duyệt mà không cần con người.

### Trong sự kiện: chỉ đường, thay đổi lịch và ngoại lệ khẩn

Hoạt động vận hành xử lý việc chỉ đường, thay đổi lịch, truy cập, sức chứa phiên, vấn đề của nhà trưng bày hoặc diễn giả và các ngoại lệ khẩn. Tốc độ và quyền sở hữu rõ ràng quan trọng nhất ở đây, và độ trễ tích hợp có hậu quả thật.

### Sau sự kiện: chứng nhận, tài liệu, hóa đơn và theo dõi

Các đội phản hồi về chứng nhận, tài liệu, phản hồi, đồ thất lạc, hóa đơn và câu hỏi theo dõi. Áp lực thời gian giảm, nhưng độ chính xác và việc lưu hồ sơ vẫn quan trọng, nhất là khi có hóa đơn hoặc dữ liệu cá nhân.

Cùng một khách có thể xuất hiện trên nhiều công cụ ở cả ba giai đoạn. Hãy quyết định hệ thống nào sở hữu danh tính và hệ thống nào sở hữu từng trạng thái vận hành, vì mọi quyết định thiết kế về sau đều phụ thuộc vào những câu trả lời đó.

## Xác định nguồn sự thật và hướng cập nhật cho mọi đối tượng vận hành

Với mỗi đối tượng trong stack, dù là khách tham dự, đăng ký, phiên, yêu cầu, escalation hay kết quả xử lý, hãy ghi lại cùng một danh sách thuộc tính ngắn: hệ thống ghi nhận, bên được phép sử dụng, hướng cập nhật, yêu cầu về độ trễ, quy tắc xung đột, quy tắc lưu trữ và người chịu trách nhiệm.

- Hệ thống ghi nhận (system of record): nơi duy nhất mà đối tượng này có giá trị chuẩn.
- Bên được phép sử dụng và hướng cập nhật: ai được đọc, và ai được thay đổi.
- Yêu cầu về độ trễ: một thay đổi cần lan truyền nhanh đến mức nào để có ý nghĩa.
- Quy tắc xung đột: phiên bản nào thắng khi các bản ghi mâu thuẫn.
- Quy tắc lưu trữ và người chịu trách nhiệm: dữ liệu được giữ bao lâu và ai giải trình về nó.

"Đồng bộ hai chiều" (two-way sync) không phải là một thiết kế đủ. Đồng bộ hai chiều phù hợp khi quyền sở hữu và quy tắc xung đột rõ ràng, và nó có thể khuếch đại lỗi khi cả hai hệ thống đều tin mình là bên có thẩm quyền. Đội ngũ cần biết hệ thống nào thắng khi bản ghi mâu thuẫn, và cần biết điều đó trước sự kiện, không phải khi hàng đợi đang dài ra.

## Chọn giữa tích hợp API trực tiếp, lớp workflow, hướng sự kiện và theo lô

![Bốn mô hình tích hợp công nghệ sự kiện được thể hiện qua các sơ đồ kết nối hệ thống đơn giản.](https://gct-solutions.net/media/serve/215/gct-solutions-choosing-between-direct-api-workflow-layer-event-driven-and-batch-integration-patterns.webp)

Không có một mẫu tích hợp nào phù hợp cho mọi workflow, và stack đúng có thể kết hợp nhiều mẫu. Bảng so sánh dưới đây tóm tắt khi nào mỗi mẫu phù hợp và cần lưu ý điều gì.

| **Mẫu tích hợp** | **Hữu ích khi** | **Cần lưu ý** |
| --- | --- | --- |
| Tích hợp API trực tiếp | Bạn có ít kết nối và chúng ổn định | Có thể khó thay đổi khi nhiều hệ thống phụ thuộc trực tiếp vào nhau |
| Lớp tích hợp hoặc workflow | Hoạt động cần định tuyến, biến đổi dữ liệu, thử lại và khả năng quan sát xuyên các hệ thống | Thêm một thành phần mà bản thân nó phải được quản trị và giám sát |
| Tích hợp hướng sự kiện (event-driven) | Cập nhật có tính thời gian và các hệ thống nên được tách rời | Cần định nghĩa sự kiện rõ ràng, tính idempotent, quyết định về thứ tự và xử lý phát lại (replay) |
| Trao đổi theo lô (batch) | Không cần dữ liệu thời gian thực | Cần kiểm tra hợp lệ, đối soát và báo cáo lỗi |

Hãy chọn theo workflow chứ không theo hệ thống. Việc đóng một phòng có thể cần lan truyền ngay qua đường hướng sự kiện, trong khi xuất analytics sau sự kiện có thể chạy an toàn dưới dạng batch có kiểm soát. Lan truyền thời gian thực làm tăng chi phí vận hành và các kiểu lỗi, nên chỉ dành cho những quyết định thực sự cần. Các đội đang cân nhắc những đánh đổi này có thể thấy hướng dẫn của chúng tôi về [thiết kế hệ thống có thể mở rộng](https://gct-solutions.net/blogs/scalable-system-design) và [kiểm thử API](https://gct-solutions.net/blogs/api-testing) là kiến thức nền hữu ích.

## Giữ ngữ cảnh hỗ trợ để một yêu cầu di chuyển an toàn giữa các hệ thống

Một yêu cầu hỗ trợ nên mang đủ ngữ cảnh để chuyển an toàn từ hệ thống hoặc đội này sang hệ thống hoặc đội tiếp theo. Tối thiểu, điều đó có nghĩa là danh tính người yêu cầu khi được phép, mã tham chiếu sự kiện và đăng ký, kênh và thời điểm, tin nhắn gốc, tri thức hoặc trạng thái hệ thống liên quan, các hành động đã thực hiện, mức ưu tiên và lý do, cùng người phụ trách hiện tại.

Đối trọng là tối thiểu hóa dữ liệu (data minimization). Tránh sao chép dữ liệu cá nhân nhiều hơn mức hệ thống nhận cần. Các hệ thống có thể trao đổi mã tham chiếu và truy xuất ngữ cảnh được phép khi cần, thay vì nhân bản toàn bộ hồ sơ khách tham dự vào mọi công cụ hỗ trợ. Ít bản sao hơn nghĩa là ít chỗ để dữ liệu lỗi thời hơn, và ít chỗ cần bảo vệ hơn.

## Mô hình hóa yêu cầu hỗ trợ thành đối tượng vận hành trong event stack

Nhiều event stack tích hợp bản ghi khách tham dự và đăng ký nhưng không bao giờ chia sẻ một đối tượng yêu cầu hỗ trợ nhất quán. Khoảng trống đó khiến quyền sở hữu và khả năng phục hồi trở nên khó khăn, vì không có gì để chuyển từ đội này sang đội khác. Một đối tượng hỗ trợ tối thiểu có thể gồm các trường sau.

| **Trường** | **Vì sao quan trọng** |
| --- | --- |
| Mã yêu cầu (Request ID) | Ngăn một vấn đề trở thành nhiều ticket không liên quan |
| Tham chiếu sự kiện và khách tham dự | Kết nối yêu cầu với ngữ cảnh vận hành được phép |
| Kênh và thời điểm nhận | Cho thấy yêu cầu vào từ đâu và đã chờ bao lâu |
| Phân loại và mức khẩn | Điều khiển định tuyến mà không dựa vào trí nhớ của người giữ hộp thư |
| Người phụ trách hiện tại | Làm lộ ra đội chịu trách nhiệm tiếp theo |
| Ngữ cảnh nguồn | Giữ lại tri thức, đăng ký hoặc trạng thái hệ thống đã dùng |
| Lịch sử hành động | Ngăn mỗi lần bàn giao phải bắt đầu lại cuộc điều tra |
| Kết quả xử lý | Hỗ trợ đối soát, báo cáo và học hỏi sau sự kiện |

Coi yêu cầu là một đối tượng có mã định danh và lịch sử chính là điều cho phép phần còn lại của thiết kế hoạt động: định tuyến, escalation, đối soát và báo cáo đều phụ thuộc vào nó. Đây cũng là chỗ tự nhiên để kết nối với CRM, vì một workflow CRM chỉ hữu ích bằng các bản ghi nuôi nó. Hướng dẫn của chúng tôi về [quy trình quản lý quan hệ khách hàng (customer relationship management workflow)](https://gct-solutions.net/blogs/crm-workflow) giải thích khuôn mẫu chung.

## Thiết kế tích hợp công nghệ sự kiện cho thử lại, trùng lặp và lỗi một phần

Tích hợp sự kiện hỏng vào những lúc bất tiện. Một thông điệp được gửi hai lần, một cập nhật đến sai thứ tự, hoặc một hệ thống chấp nhận thay đổi mà hệ thống khác từ chối. Thiết kế cần nói trước điều gì xảy ra. Hãy định nghĩa hành vi thử lại (retry) và giới hạn của nó, cách ngăn trùng lặp, cách giữ và rà soát thông điệp lỗi, báo cáo đối soát nào tồn tại, con người phục hồi thủ công ra sao, ai sở hữu việc giám sát và cảnh báo, và hoạt động vận hành chạy thế nào ở chế độ suy giảm khi một nền tảng không khả dụng.

Quan trọng nhất, hãy kiểm thử đường lỗi trước sự kiện, không phải trong sự kiện. Rút một kết nối khỏi chuỗi trong buổi diễn tập và quan sát đội ngũ làm gì. Những khoảng trống lộ ra trong diễn tập chính là những khoảng trống nếu không sẽ xuất hiện ngay trước mặt khách tham dự.

## Giữ AI bên trong mô hình kiểm soát của event tech stack

Nếu AI giúp phân loại, tóm tắt hoặc định tuyến yêu cầu hỗ trợ, thiết kế tích hợp nên ghi lại đầu ra của mô hình, ngữ cảnh nguồn, chỉ báo độ tin cậy hoặc rủi ro, hành động cuối cùng của con người và phiên bản mô hình hoặc cấu hình quan trọng. Bản ghi đó cho phép đội ngũ giải thích, về sau, vì sao một yêu cầu được xử lý theo cách đã xảy ra.

Một phản hồi do AI sinh ra không được phép vượt qua các quy tắc về danh tính, truy cập hay escalation đã được thực thi ở nơi khác trong stack. AI có thể tạo giá trị bằng cách phân loại, tóm tắt, truy xuất tri thức đã duyệt hoặc đề xuất đường định tuyến, nhưng hệ thống bao quanh vẫn phải là thứ thực thi ai được thấy gì và ai phải phê duyệt gì. Nguyên tắc này cũng xuất hiện trong bài của chúng tôi về [xây dựng quản trị AI vào bên trong hệ thống, không chỉ nằm trong tài liệu chính sách](https://gct-solutions.net/blogs/ai-governance-in-the-system), và Văn phòng Ủy viên Thông tin Anh (ICO) mô tả cách tiếp cận của họ ở lĩnh vực này trong [hướng dẫn về AI và bảo vệ dữ liệu](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/about-this-guidance/). Đây là thông tin chung, không phải tư vấn pháp lý.

## Chuỗi tích hợp trong ngày diễn ra: điều gì xảy ra khi lịch phiên thay đổi

![Thay đổi lịch sự kiện đi qua bước xác thực, thông báo đến người tham dự và cập nhật hồ sơ hỗ trợ.](https://gct-solutions.net/media/serve/214/gct-solutions-a-day-of-integration-sequence-what-happens-when-a-session-schedule-changes.webp)

Hãy xét một ví dụ minh họa: một thay đổi lịch ảnh hưởng đến một khách đã đăng ký. Một tích hợp được thiết kế tốt đi qua chuỗi sau.

> 1\. Hệ thống chương trình hoặc sự kiện công bố thay đổi đã được duyệt.
>
> 2\. Lớp tích hợp kiểm tra tính hợp lệ của sự kiện, phiên và thời điểm có hiệu lực.
>
> 3\. Kênh hướng tới khách tham dự cập nhật nội dung hoặc trạng thái thông báo.
>
> 4\. Yêu cầu hỗ trợ liên quan thừa hưởng ngữ cảnh nguồn mới.
>
> 5\. Các câu hỏi tiêu chuẩn có thể được giải quyết từ bản cập nhật đã duyệt.
>
> 6\. Ngoại lệ về tiếp cận, đi lại hoặc VIP được định tuyến tới đội con người được chỉ định.
>
> 7\. Hành động cuối cùng và thông tin liên lạc quay về bản ghi hỗ trợ.
>
> 8\. Đối soát xác nhận các kênh trọng yếu đã nhận bản cập nhật.

Chuỗi này cố tình không gắn với sản phẩm cụ thể. Nó mô tả hình dạng của một thiết kế tốt, bất kể công cụ nào triển khai, và mọi phiên bản theo sản phẩm cụ thể nên được đối chiếu với các kênh được hỗ trợ, mẫu tích hợp, ranh giới dữ liệu và người chịu trách nhiệm vận hành của đợt triển khai đang xét.

## Xác định mô hình vận hành trong ngày: ai theo dõi tích hợp và hàng đợi hỗ trợ

Tích hợp kỹ thuật không quyết định ai xử lý một workflow đang lỗi. Trước sự kiện, hãy thống nhất đội nào theo dõi các tích hợp và hàng đợi hỗ trợ, điều gì được tính là sự cố kỹ thuật so với ngoại lệ vận hành, đường escalation và mục tiêu phản hồi theo mức nghiêm trọng, ai được sửa dữ liệu nguồn, đội ngũ làm việc thế nào khi một nền tảng không khả dụng, khi nào dùng thông báo thủ công hay trang trạng thái, và sự cố cùng các yêu cầu chưa giải quyết được rà soát ra sao sau đó.

Dashboard giá trị nhất không nhất thiết là cái có nhiều sự kiện nhất. Nó nên cho thấy các yêu cầu quá hạn, ngoại lệ chưa có người sở hữu, các lần chuyển dữ liệu thất bại, dữ liệu nguồn lỗi thời và các mốc kinh doanh đang gặp rủi ro. Đó là những tín hiệu cho trưởng vận hành biết cần nhìn vào đâu tiếp theo.

## Rà soát mức sẵn sàng tích hợp cho công nghệ sự kiện trước sự kiện tiếp theo

Tổng hợp các phần trước, một bản rà soát mức sẵn sàng tích hợp có thể theo tám bước.

> 1\. Liệt kê các hệ thống và người sở hữu.
>
> 2\. Lập bản đồ các workflow vòng đời trước, trong và sau sự kiện.
>
> 3\. Xác định hệ thống ghi nhận cho từng đối tượng.
>
> 4\. Phân loại dữ liệu và quyền.
>
> 5\. Chọn mẫu tích hợp theo workflow.
>
> 6\. Chỉ rõ cách xử lý lỗi và đối soát.
>
> 7\. Kiểm thử với các kịch bản sự kiện thực tế.
>
> 8\. Giao việc giám sát và escalation trong ngày diễn ra.

## Trợ lý vận hành AI có thể phù hợp với kiến trúc event tech này ra sao

![AI operational assistant kết nối các kênh tương tác đã được phê duyệt với hệ thống và đội ngũ hỗ trợ sự kiện.](https://gct-solutions.net/media/serve/217/gct-solutions-how-an-ai-operational-assistant-may-fit-this-event-tech-architecture.webp)

Vận hành sự kiện là một ứng dụng trong định hướng trợ lý vận hành AI rộng hơn của E-INNA, được mô tả trong bài của chúng tôi về [E-INNA như một trợ lý vận hành AI cho hệ thống hỗ trợ có thể mở rộng](https://gct-solutions.net/blogs/e-inna-enterprise-ai-assistant-customer-operations). Trong ứng dụng này, E-INNA có thể nằm giữa các điểm chạm khách tham dự đã duyệt và các đội, hệ thống, tri thức tham gia cung cấp hỗ trợ. Vai trò dự kiến là giúp hiểu yêu cầu, truy xuất thông tin có quản trị, đề xuất hoặc thực hiện hành động đã duyệt, giữ ngữ cảnh khi định tuyến hoặc escalation, và hỗ trợ khả năng quan sát vận hành.

Mô tả đó nêu một định hướng, không phải cam kết rằng mọi bước trong bài đều được tự động hóa ở mọi đợt triển khai. Phạm vi tích hợp phải được xác nhận cho từng dự án, và những gì được hỗ trợ công khai được mô tả trên [trang tổng quan giải pháp E-INNA](https://gct-solutions.net/solutions/e-inna-enterprise-ai-assistant). Kiến trúc cũng nên giữ quyền kiểm soát của con người: các ca nhạy cảm hoặc tác động lớn có thể cần một phản hồi gợi ý hoặc đường định tuyến được đề xuất thay vì thực thi tự động, với đội chịu trách nhiệm và quyết định cuối cùng luôn hiển thị. Để có góc nhìn bổ sung về phía hỗ trợ trong ngày diễn ra, xem bài của chúng tôi về [vận hành sự kiện thực sự cần gì trong ngày diễn ra](https://gct-solutions.net/blogs/event-operations-requirements-on-the-day). Để trao đổi về stack của riêng bạn, hãy [trao đổi với đội ngũ GCT về E-INNA](https://gct-solutions.net/contact).

## Lời kết: tích hợp công nghệ sự kiện tốt thì "yên ắng" trong ngày diễn ra

Các hệ thống trong event stack sẽ thay đổi từ mùa này sang mùa khác, và các mẫu tích hợp phù hợp với chúng cũng vậy. Điều bền vững là một bộ câu hỏi về trách nhiệm: hệ thống nào là bên có thẩm quyền, ai sở hữu yêu cầu ở mỗi thời điểm, và bằng chứng nào còn lại sau đó. Một thiết kế trả lời rõ những câu hỏi này thường vượt qua các lần đổi công cụ mà ít xáo trộn.

Dấu hiệu tốt nhất của một tích hợp vững là nó yên ắng trong ngày diễn ra. Bản cập nhật đến đúng nơi, ngoại lệ tìm được người xử lý, và sự cố nhỏ, nhìn thấy được và khôi phục được. Sự yên ắng đó hiếm khi là ngẫu nhiên. Nó là kết quả của những quyết định về quyền sở hữu được đưa ra từ rất lâu trước khi vị khách đầu tiên đến.

## Câu hỏi thường gặp về tích hợp công nghệ sự kiện và quy trình hỗ trợ

**Mọi cập nhật hệ thống sự kiện có phải là thời gian thực không?**

Không. Hãy chọn độ trễ theo quyết định. Việc đóng một phòng có thể cần lan truyền ngay, trong khi xuất analytics sau sự kiện có thể xử lý an toàn theo lô có kiểm soát. Thời gian thực làm tăng chi phí vận hành và các kiểu lỗi.

**Đồng bộ hai chiều có tốt hơn giao diện một chiều không?**

Chỉ khi quyền sở hữu và quy tắc xung đột rõ ràng. Đồng bộ hai chiều có thể khuếch đại lỗi khi cả hai hệ thống đều tin mình là bên có thẩm quyền.

**AI có thể tạo giá trị ở đâu mà không sở hữu workflow?**

AI có thể giúp phân loại, tóm tắt, truy xuất tri thức đã duyệt hoặc đề xuất đường định tuyến. Các quy tắc về danh tính, truy cập, nguồn sự thật và escalation vẫn nên do hệ thống bao quanh thực thi.

**Một đợt thí điểm (pilot) nên tạo ra bằng chứng gì?**

Tối thiểu: hợp đồng giao diện, các ca kiểm thử, kết quả thử lại và đối soát, người phụ trách trong ngày diễn ra, quyết định về quyền riêng tư và một buổi diễn tập sự cố. Chỉ thêm ảnh chụp sản phẩm hoặc số liệu sau khi được duyệt.

## Đọc tiếp

- [Vận hành sự kiện thực sự cần gì trong ngày diễn ra](https://gct-solutions.net/blogs/event-operations-requirements-on-the-day)
- [E-INNA: An AI Operational Assistant for Scalable Support Systems (Trợ lý vận hành AI E-INNA cho hệ thống hỗ trợ có thể mở rộng)](https://gct-solutions.net/blogs/e-inna-enterprise-ai-assistant-customer-operations)

Khám phá thêm từ GCT Solutions tại [trang chủ GCT Solutions](https://gct-solutions.net/), hoặc xem cách chúng tôi tiếp cận [software engineering](https://gct-solutions.net/services/software-engineering) và [hiện đại hóa nền tảng (platform modernization)](https://gct-solutions.net/services/platform-modernization).

## Nguồn tham khảo

- Cvent: [MarTech và tích hợp công nghệ sự kiện (MarTech and event-tech integration)](https://www.cvent.com/en/blog/events/martech-event-tech)
- Văn phòng Ủy viên Thông tin Anh (ICO): [Hướng dẫn về AI và bảo vệ dữ liệu (Guidance on AI and data protection)](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/about-this-guidance/)