Queryless client concerns based on meetings

Malmo

Concern that one user could send many requests, or more complex requests, and drive costs up. In the meeting, this was framed around the fear that some queries might be much more expensive than others.
Concern about API abuse or misuse driving unnecessary usage and cost. Johan explicitly said they need a way to block misuse so it does not keep running and increasing cost.

Are there examples of other public-sector teams doing something similar that we should look at? This was asked in the context of seeing what other cities are doing in this space and using those examples as reference points.

Concern that they do not have many users and do not have enough strong raw datasets to make the upside large. They contrasted their portal with larger cities that have more data and more obvious AI use cases.
Concern that uploaded data may have strange structure and the tool could return wrong results. They referenced the trash data example and the possibility that imperfect source data could lead to incorrect answers.
Concern that this could have the same limits as self-service BI, where important table context is missing and the AI is overconfident. They described this as a familiar problem where insiders know the caveats of a table but end users and AI do not.

Can it look for data quality indicators or gaps in a dataset?
Can it use data from different pages, datasets, or resources in one report? This came from interest in combining information across portal content rather than staying inside one dataset.
Can it bring data together from different datasets into one file? They were asking about creating bespoke merged outputs for users.
Can users export that combined result as CSV? This followed naturally from the previous question and was framed as a practical user need.
If some datasets are restricted, would the AI respect user permissions and avoid pulling data the user cannot access? This was asked as a security and access-control check.
Do you have any energy-industry datasets or examples we could look at? They wanted to see the product against data closer to their own domain.
Are there examples of this already being used by other organizations? They asked this to understand how mature and proven the product is.
If the model suggests something dangerous or unsafe, where does liability sit? This was raised specifically because some outputs could affect real-world infrastructure decisions.
Will there be standardized guardrails, content moderation, and disclaimers? This came up as part of making the tool safe enough for their use cases.
Will SSEN be able to give input into those guardrails? They wanted to know whether those protections could be shaped around their own standards and risks.

Data quality is a big concern for their data consumers. This was stated directly during the discussion around whether the tool could identify issues or gaps.
Opening this to web search could increase hallucination or misinformation risk. They were comfortable with grounded portal data and more cautious about anything broader.
Unsafe answers matter because some data relates to underground assets and similar infrastructure. Their example was that a bad answer could influence where someone thinks it is safe to dig.

Is it possible to trace the process behind how charts or answers were generated? This was asked as a transparency question about whether users can inspect how an answer was produced.
If someone asks for data that is not in the portal, will it say that clearly or point to something similar? This came from wanting to understand failure behavior when the requested topic is missing.
Is there any safety mechanism to prevent very heavy API usage from affecting the portal? This was asked in the context of protecting the CKAN API from overuse.

Concern that external collaborators or contractors could accidentally overload or DDoS the portal. They mentioned this specifically in relation to third parties building complementary tools against TDC data.
Concern that TDC does not currently have mandate or funding to pursue this work directly. This was positioned as an organizational constraint on near-term adoption.