How to plan MarTech architecture for marketing AI

A robust MarTech architecture answers five questions before any integration: which system is the authoritative source for each kind of data? Which data may flow for which purpose? How are people, events and content referenced unambiguously? Who handles errors? And how can a component be switched off or replaced? Only once these answers are documented should an AI service be embedded in a marketing process. An architecture diagram on its own is not enough; what matters are the data formats, meanings, access rules and failure handling agreed between the systems.

Architecture starts with responsibility boundaries

Do not start by listing products, but business capabilities: managing contacts, approving content, serving campaigns, respecting consent, capturing events, analysing results. Assign each capability exactly one business owner and, where possible, one system of record. “The CRM and the marketing platform both know the contact” is not yet a decision. You still have to clarify which system holds the primary identity, which one may accept changes and how conflicts are resolved.

That boundary prevents an AI service from quietly becoming a second system of record. A model can, for example, suggest a subject line or classify a record. But it should not decide on its own whether consent is valid, overwrite a contract status or merge two identities. Such state changes need deterministic rules, authorisation and a traceable source.

The five layers of an integration map

The first layer contains the source systems. These can include CRM (customer relationship management), CMS (content management system), DAM (digital asset management), shop, analytics or advertising platform. For each source, note the data owner, the refresh cadence and known quality limits. “Customer data” is too vague. Name concrete fields and their purpose: contact ID, language, product status or approved copy block.

The second layer is identity. People, companies, campaigns, assets and events need stable keys. Email addresses change and should not serve as a universal identity without scrutiny. Define which key is used across systems, how duplicates are detected and which merges are prohibited. If an identity cannot be matched reliably, use an explicit hold or stop path; anonymised processing is permitted only where it is allowed for the purpose.

The third layer is the data contract. It describes not only a JSON schema but also the meaning, origin, purpose, freshness and quality rule of a field. A field such as “score = 0.8” is barely usable without a model version, a scale and a validity timestamp. A contract should cover required fields, permitted values, versioning, the deletion rule and behaviour with unknown fields. That makes an interface verifiable before a model draws conclusions from it.

The fourth layer is orchestration. It decides whether a process waits synchronously for a response, processes an event asynchronously or exchanges a batch file periodically. That choice has consequences. A synchronous chain can block the visible process during an outage. An asynchronous event needs duplicate prevention or detection and a defined ordering. A batch's data can be stale; the batching mechanism itself is not obsolete because of that. The architecture should name the business requirement, not simply choose the technically most modern option.

The fifth layer covers observability and operations. Every handover needs a technical status, a correlation ID, a timestamp and a queue with clearly assigned responsibility. Logs must help explain a transaction but must not expose unnecessary personal data or prompts. A dashboard without clearly assigned responsibility is just a display. Define who reacts to which error, which processing can be safely retried and when the process is stopped.

Point-to-point, integration layer or modular components?

A direct connection between two stable systems can be sufficient. The problem arises when every application knows every other application directly: changes then multiply tests, credentials and dependencies. An integration layer can translate formats, distribute events and observe access centrally. It must not, however, become an undocumented monolith that hides all business logic.

The MACH Alliance describes open, composable and connected architecture as the interplay of documented, portable components, independently replaceable functions and interoperable connections designed on API-first lines (API = application programming interface). That can be useful for organisations with many independent capabilities, but it is not an end in itself. A small team may fare better with a few well-bounded systems, stable APIs and clean operations than with dozens of microservices. The decision depends on the rate of change, team structure, risk and operational capability.

In this context, API-first means treating the interface as a product with precise commitments about how it behaves. It has an owner, a version, documented errors, permissions, limits and a policy for retiring older versions. “There is an API” is not a sufficient selection criterion. What matters is whether the required data flow can be mapped completely, securely and testably.

An AI component needs a tighter boundary

With a conventional rule-based service, the same input is usually tied closely to the same output. A generative model can vary. The integration contract must therefore also carry the model or service version, the prompt template, permitted knowledge sources, the output format, the validation status and human approval. Do not store only the result, but the provenance needed for a later review, insofar as data protection and retention rules permit.

A model must not receive rights it does not need for its task. If it drafts a text, it does not automatically need write access to the CMS. If it analyses a campaign, it does not automatically need mutation rights. Proposal and execution should run through separate technical identities and endpoints. The execution path checks authorisation, version and approval independently of the model.

Credentials belong neither in prompts nor in hidden system instructions. OWASP points out that a system prompt is not a secret and not an authorisation layer. Secrets belong in a dedicated store; access should be time-limited where supported and limited by the principle of least privilege. The model context receives only the information the specific task requires.

Assess data protection for each data flow

The question “Is the tool compliant with the Swiss Data Protection Act?” is too broad. What is assessed is a specific processing operation: purpose, data categories, origin, recipients, storage locations, retention and the rights of the people concerned. The Federal Data Protection and Information Commissioner (FDPIC) states that this Act applies directly to AI-supported processing of personal data. Where its conditions are met, a data protection impact assessment is a legal requirement.

In the architecture plan, therefore, do not just draw arrows: label every arrow with its purpose and data class. Mark whether data leave the organisation or the country, whether a subprocessor is involved and how deletion or access requests are passed on. This map does not replace a legal review, but it makes one concrete.

Error paths are part of the architecture

Plan for at least: timeout, invalid response, partial processing, duplicate event, stale input, revoked permission and an unavailable third-party provider. Every case needs a safe state. A retry must not create a duplicate message or a duplicate change. A “dead-letter” queue needs an owner and a retention period. A fallback must not bypass the safeguard.

Plan how to replace or leave a service from the outset. Can data, templates, audit logs and configurations be exported? Which proprietary IDs have to be translated? What happens when an API version ends or a model is withdrawn? Current official UK guidance on adopting and procuring GenAI tools emphasises organisational risks, training, support and ongoing monitoring. These questions make it possible to change providers or components without losing control of the process.

Test architecture decisions and contracts together

Record material decisions in short architecture decision records (ADR): context, options, chosen solution, rejected alternatives, consequences and revision date. A record is not a justification after the fact. It shows the next team why a synchronous call, an integration layer or a particular responsibility for maintaining authoritative identifiers was chosen, and on which change the decision must be reviewed.

Complement diagrams with automated interface-contract tests. A test can check whether required fields are present, unknown schema versions are rejected, write access without approval fails and repeated events produce no duplicate effect. Another test simulates the failure of a third-party provider and verifies the safe state. Such tests do not prove overall architectural quality, but they make critical assumptions reproducible.

Plan for capacity and limits as well. A model or API service can be slow, throttled or more expensive than expected. The architecture needs ceilings per period, queues and a rule for which operations are prioritised or stopped when capacity is tight. Cost warnings are operational signals, not a licence to bypass quality or data protection controls.

Migrate in small, reversible increments

A “big bang” ties too many assumptions together. Start with a read-only data flow and synthetic test cases. A shadow run can then produce results without affecting the operational process. Only once identity, schema, error handling and review are stable does a limited write action follow. Each stage has measurable acceptance criteria and a rollback.

The architecture decision is ready when the capability map, systems of record, identities, data contracts, permissions, error owners, logs, retention and exit are documented. If that is missing, no additional AI component should paper over the ambiguity. This checklist helps with planning; it does not mean that a MarTech implementation is included in the Google Ads product. If a clearly scoped part concerns Google Ads alone, its current state can be audited separately and read-only; that audit does not automatically inspect an external CRM or website.

How maitiq helps: tracing a lead's full journey through all systems

Map the path from the enquiry through the CRM to the sales feedback. For each handover, define the identifier, the required fields, the responsible system and the error handling. A failed transfer must become visible; a retry must not create the same lead twice.

An agreed initial assessment can clarify which handovers and data flows are really needed; any implementation that follows is agreed separately. A good integration reduces manual transfers and preserves the meaning of the data. Success is measured by complete transfers, error rate and manual rework, not by the number of connected tools.

How a first pilot with maitiq begins

An agreed initial assessment shows which connection is really needed, where unnecessary data or permission creep arises and what a controlled implementation requires. You receive a defined use case and a record of unresolved data and control questions, a pilot plan and the criteria for later operations. Any implementation is agreed separately.

Decision rule: Map the minimal data flow and the permitted action first; choose the technology only afterwards.

Sources and how to read them

The FDPIC explains the data-protection requirements for AI; OWASP describes security risks and countermeasures; the MACH Alliance sets out an industry association's principles for composable architecture. Read each source for that purpose. Information about how maitiq works is available at maitiq.com.

Have maitiq review your specific case.