This is Icebreaker One’s response to The Department of Business and Trades’ Smart Data 2035: The UK’s Smart Data Strategy.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Call for input response

Prioritisation of sectors and use cases

Through IB1 programmes and years of expertise, IB1 supports following a use case approach to data sharing initiatives. This approach centres user needs, makes a business case for the investment in data sharing, and allows for:

  1. Market incentives: there must be an economic argument that policy can then amplify or mandate. If there is no financial incentive, there will be no movement.
  2. Removal of transactional friction: There must be “something in it” for everyone, or at least a path to cost reduction or a new business model. Removing friction can help everyone go together: this is never solely a ‘technology problem’ (e.g. absence of a data ontology).
  3. Documentation with the identified problem statement, actors and stakeholders, a clear goal, and the envisaged impact. 

Smart Data becomes effective when it is connected

In terms of prioritisation of sector, use cases requiring cross-sector interoperability and cohesion offer the greatest immediate ability to create impact, with a manageable degree of complexity involved in rollout. These use cases support private sector growth and require achievable government intervention, allowing green growth and environmental goals to be met.

User and customer needs should be identified through a robust governance process which can understand, process, and define use cases with relevant stakeholders. In IB1’s Scheme governance (standard operating procedures), IB1 emphasises the importance of having a user needs & impact advisory group which explores, prioritises, and works through use cases (including identifying users, their needs, and mapping data value chains). This process allows for the development of business, value, and impact cases and their impact on policy, businesses, and financial instruments. 

To maximise the benefits, use cases must:

  • Address governance, user needs, business, social, legal, engagement and communications to ensure the solution is fit for purpose, and can be adopted by the market. IB1 observes that technical-led programmes tend to fail to gain traction or deliver against material user needs.
  • Foster a community to ensure there is cross-sector collaboration. IB1 strongly recommends taking a joined up approach which is interoperable with initiatives across the economy. IB1 suggests defining relationships with adjacent bodies in the sector and beyond to enable cross sector interoperability.

For identified energy use cases, see IB1’s response to DESNZ energy smart data scheme call for evidence question 14. 

The interplay between industry and government progress in developing schemes or regulations, and how to encourage fast progress

It is important that progress toward sharing data is incentivised before waiting for one perfect data sharing solution to be built as there is demand for data immediately. 

For example, in the near-term it is unlikely that the energy data sharing infrastructure (DSI) will be suitable for all use cases, as it is currently unclear when and how non-regulated actors will be able to access data via the DSI, for what purposes, and under what assigned roles. These actors constitute major customers for connections data (e.g. heavy industry, retail, local authorities etc). While they may well be users of the DSI in future, opportunities to service these data customers in a secure, structured and well-governed manner must not be put on hold until the DSI is ready. 

As there is demand by non-regulated users for data now, there would be benefits to developing high-impact schemes in the short term that operate autonomously, but are legally and technically structured to facilitate integration with future common data sharing infrastructure. It is essential that as the government makes progress on developing schemes and regulations that they do not block valuable industry initiatives from being established quickly.

The coordination layer

To enable valuable government and industry schemes to progress quickly in parallel while remaining coherent and interoperable, IB1 strongly recommends intentional coordination of the cross-programme rules, standards, credentials and access controls that make data flow possible at scale. We recommend that responsibility for the coordination layer sits in an independent mission-locked entity that holds – or subcontracts – the sector’s Trust Framework and provides the sector’s neutral data coordination function. While different ownership options exist, industry co-ownership and co-Directorship of such a body provides a meaningful route for ensuring stakeholder buy-in and co-funding, akin to the model of Open Banking Ltd.

A neutral data coordination function must consider:

  • How will schemes’ governing bodies coordinate with developments within and beyond their own scope? 
  • How will this feed into goals, design choices, and definition of technical/architectural parameters? 
  • How might this need to evolve over time? For example, sectoral coordination laddering up to cross-sector.
  • How might Scheme development interact with overarching sector and national data/digitalisation strategies?
  • How can Schemes encourage competition, markets and service creation within and across boundaries?

The coordination function requires a Secretariat to act as a neutral facilitator for participatory governance processes which can adapt flexibly to evolving coordination needs and ensure accountability. This requires:

  • Strong governance processes – e.g. covering participant selection, means of input, minuting, reporting, and decision-making
    • Ability to offer tailored mechanisms where required – e.g. working groups to focus on specific sectors or data flows, or task-and-finish groups to support elements of data strategy delivery.
    • Flexible staffing, with ability to take on additional domain specialists/contractors as necessary
  • Experienced administrators to execute governance processes and communicate expectations of timescales, plans, key decisions etc.
  • Where required, the provision of independent chairing or facilitation services
  • Dispute resolution processes, linked to existing sector mechanisms and to individual Scheme governance processes where relevant.
  • Participant accountability mechanisms 
  • Commitment to open publishing as a default approach (unless there is strong reason to do otherwise) 

It is vital for the coordination body to be fully independent; it cannot be nested in a body with pre-existing market functions without risking conflict of interest or transparency problems. 

Effective coordination should also be supported by monitoring in two key areas:

  • Mapping of the domain(s) in which coordination is enacted in order to support effective participatory governance in an ongoing manner
  • Monitoring and reporting on the outcomes of coordination activity to improve transparency and join-up with adjacent policy/regulatory goals
    • Where relevant, this may additionally include monitoring the delivery of a sector’s data strategy / roadmap.

We suggest that the above activities would require a small permanent staff to ensure continuity of process and expertise, with additional needs met via subcontracting and secondment on a time-limited basis for agile response to emergent needs (e.g. particular technical or domain expertise concerning a coordination challenge). This lightweight approach delivers the intended benefits at a reasonable cost to the bill or tax payer, supporting the general principle of minimisation outlined earlier in this response.

Finally, we propose that any enforcement powers for the coordinator can be most readily delivered via existing regulatory and legislative capabilities. This reduces cost and risk of establishing new statutory bodies.

Best practice in scheme design, including for vulnerable and other consumers, and to maximise how well the system works for services that use data from more than one sector

A core centralised capability must be the design principles. Critically, aligning on design principles for governance will lead to greater cohesion and interoperability of outcomes. 

Governance processes should collaboratively agree upon:

  • The intent to work toward interoperability and working in widely understood formats. 
  • Licence compatibility – creation of preemptive multilateral contracts/agreements, including appropriate permissioning where required
  • Human- and machine-readable representations of scheme rules
  • Adoption of common open web standards as the default (unless insufficient) to allow for widest possible number of technologists to understand
  • Open publication of new specifications (legal, procedural and technical) that may be adopted by other schemes to aid interoperability
  • The use of consistent tooling that is well understood by stakeholders
  • Appropriate proven security standards
  • The use of open source 
  • Conceptual alignment on what metadata means (better yet  – technical compatibility), and aligning around standards

Within this governance function, there must be adequate consideration of the amount of communications and time needed to convene, design, implement and develop consumer messaging for schemes.

To enable interoperability, IB1 recommends considering how Schemes will interact. Key aspects of this are:

Identity. IB1 suggests this should not be a centralised identity, but a mechanism which can enable cross scheme identity verification. This is a key area of research with further needs around how a federated identity system may work. IB1 is exploring this within Perseus, to enable an identity interaction with Open Banking’s identity establishment. 

Access, licensing and permissions. There is a need to invest in research into this, as uncertainty in rights to access, use, combine, sell or share data is a drag on innovation and introduces unnecessary cost. Different regulatory environments can lead to additional confusion for cross-sector data use. There is potential to develop permissioning and purpose representations that can be understood readily by data users and their customers, but interpreted at scale by machines.

Assurance: Schemes need to address the assurance needs of data users in order to deliver value. Considerations include provenance, quality, processes, auditability, liability and redress. Protections for scheme participants (companies) and the customers they serve must be clear. A common language and machine-readable representation for these aspects of data sharing enables confident use of data and accelerates adoption.

Potential cross-sector innovation support, or data or regulatory sandbox services, and how they are designed 

IB1 recommends investment in common tooling to develop public digital infrastructure and open source support which can be re-used across schemes. 

There is a potential role for the National Data Library to curate common standards for scheme rules and their representations and convene the working groups that define them.

The places and methods through which competition should be enabled or promoted in the smart data system, and the pros and cons involved

Scheme development will be a part of the public digital infrastructure development, with appropriate governance oversight to avoid anticompetitive practices, and to guard against cartels to ensure it is a fair place to do business. IB1 thinks of this as “collaborate on the [data sharing] rules, compete on the [services] game.” It is part of the governance process to delineate what is considered pre-competitive and to have short term targeted projects (e.g. mapping stakeholders who must be consulted when developing a specific area of pre-competitive activity).

IB1 also recommends to include value-mapping guidance in the handbook (recommended approaches to do it for a scheme) and to identify and caution against perverse incentives.

Underlying trust services (for example identity, verification, compliance monitoring, permission management, version-controlled registries of scheme rules) must have open standards, ideally with Open Source reference implementations. Scheme operators should have a competitive market of trust service providers to choose from, whose services comply with these standards. The aim is to create a market that operates along the same lines as the HTTP web standard and web hosting providers. 

Methods and forums for engagement with those outside government and join-up between sector-level and cross-sector developments (such as the guidebook)

  • Opportunity to capitalise on existing data sharing governance forums:
  • Any coordinating entity must be accountable to its stakeholders. We suggest this is supported by the following:
    • Openness policies enabling scrutiny (e.g. of methodologies, processes, minutes, reports)
    • Where required (for security purposes), clear rules defining how scrutiny will be undertaken among closed audiences
    • Defined process for dispute resolution integrated with existing sector mechanisms
    • Clear processes for change management
    • Defined avenues for external involvement in participatory processes
  • Wider engagement than just the incumbents and/or regulated entities within a sector (e.g. in the energy sector this must include actors beyond the roles licensed by Ofgem)
  • Cross sector convening needs to be around coherent use cases with a wide range of stakeholders representing the different roles and stakeholders within the data value chain

Join-up between smart data and other data policy, and with international partners

There are developing debates in sectors such as energy and property as to what is considered under the realm of smart data, versus what is considered ‘system data’  There is potential for some issues emerging there and in other sectors which need to be considered and worked through with the relevant stakeholders. Definitions established under the Data Use and Access Act must be respected where relevant.

It is worth noting that not all data is smart data but will need to interact with other data which could/should be shared for key use cases. We caution against excluding ‘non-smart’ data stakeholders when convening around smart data and other data policy. 

Our most prominent international partner – the EU – has invested heavily in technical infrastructure via its Gaia-X initiative. Outcomes have been mixed, due in part to an apparent assumption that “if we build it they will come”. Recent work by the Data Spaces Support Centre on design principles and governance has the promise to encourage more use cases to be brought forward and be implemented. The UK should have a goal of alignment with EU developments on data spaces, but to aim for eventual harmonisation (as with the advice on interoperability within the UK above) as opposed to full technical interoperability at an early stage. As with all data sharing work, the use case is key here. If a use case requires interoperability with EU dataspaces, or interoperability drives very high value, then it is worth the investment to align and connect. Many use cases will not require this, at least in their initial phases.

Links between smart data and AI adoption and innovation, either within the Industrial Strategy sectors or more widely across the economy. 

AI is moving rapidly from performing tasks for people (“summarise this document in under 300 words”, “tell me the top considerations when buying a new fridge”) to performing tasks on behalf of people (“deploy this software”, “find and book a reasonably-priced vegetarian restaurant in Soho for me and 3 others next Thursday evening”). To perform these tasks, agents will need to access the instigator’s personal data, and to exercise delegated authority to act on their behalf. Both of these may implicate multiple providers, using data and access that the instigator didn’t foresee.

AI and smart data intersect in governance and assurance, enabling trust in AI operation by answering questions such as: 

  • Where is personal data stored and processed, and to whose benefit?
  • Where did the data the model is using come from? (Both for training and for retrieval-augmented generation)
  • What personal data did the model use?
  • How much reliance can the user put on the inference?
  • How are permissions delegated to AI, and how are consumers protected?
  • How does the agent ensure that personal information is protected under GDPR when shared?

Relevant materials

Please see other relevant IB1 call for evidence responses:

General principles

Additional comments:

  • Reusability: the methodology for exploring and getting Schemes off the ground can have generic/reusable items. But the Schemes themselves must have capacity for tailoring.
  • Minimisation: Schemes should do the minimum possible that enables the use case to be addressed.